Where Is Your Data, Really? Understanding Hosting, Residency, and Recovery

Most HR leaders can describe what their system does. Far fewer can answer a simpler question: where is it?

Not in the abstract sense — “we’re on the cloud” — but specifically:

• Which physical servers hold your employee data. 
• In which country those servers are located. 
• Who owns and operates the facility. 
• What happens to your data if that facility experiences a fire, a flood, a power failure, or a ransomware attack. 
• Is there a second copy of your data somewhere else, and how current is that copy?
• How long it would take to restore normal operations if the primary system went down.

These are not technical questions that can be safely delegated to IT and forgotten. They are organizational questions with legal, operational, and compliance implications that HR leaders and executives need to understand — particularly as data privacy regulations across Southeast Asia increasingly specify not just how data must be protected, but where it must be stored.

In the earlier articles, we looked at how HR data behaves — how it moves through different states, and how access to it is controlled. This raises a more practical question: where do those states actually exist? 

This is what this article focuses on: the infrastructure layer of HR data security — where that data actually sits, and how those locations shape the level of protection it receives. 

But before getting into those specifics, it is worth addressing a more fundamental misconception — one that shapes how most organizations think about this topic.

Where HR data actually lives: more places than you think

When organizations talk about “their HR system,” they usually picture a single application — the HRIS where employee records are stored and managed. The assumption that follows is that protecting the system means protecting the data.

Most HR data exists across four distinct types of environments:

The primary system — the HRIS database, hosted in a cloud environment or on-premise infrastructure, which acts as the central repository for employee data. 

This is typically where the strongest controls are applied: encryption, access control, audit logging, and system-level monitoring. It is usually the most mature and best-protected environment. 

But it is not the only one.

Backups and recovery environments — scheduled database snapshots, geographically separate disaster recovery environments, and long-term archival storage. 

These copies are essential — without them, data loss events would be irreversible. But a backup is still data, and its protection depends on how it is configured, not merely on its existence. The assumption that “backups are handled” is common. The reality is that their security is only as strong as the controls applied to them.

Integrated systems and external platforms — payroll processors, banking systems, benefits providers, recruitment platforms, and analytics tools. 

Each integration involves data being transmitted, received, and often stored outside the core HRIS. Each connection is, effectively, another location where employee data resides, with its own access model and its own potential points of failure.

Data outside the system entirely — exported reports, spreadsheets, email attachments, locally downloaded files, data copied into presentations or documents. In practice, this is where the largest gap between perceived and actual protection tends to appear. 

The moment data leaves the system, it also leaves the system’s controls. There is no longer any role-based access control, audit log, centralized authentication, or data retention policy governing what happens to it. What remains is whatever controls exist in the environment where the data has been moved, which may be significantly weaker.

This last point deserves particular attention, because it is where assumptions about system security most often break down. Exporting data from the HR system is not an exceptional event. It is part of daily operations. HR administrators generate reports. Managers review spreadsheets. Data is shared to support decision-making. Each of these actions creates a new instance of the same data, outside the boundaries of what most organizations consider when they evaluate their security position.

The system remains centralized. The data, in practice, becomes distributed. Security gaps rarely originate in the core system — they appear in the spaces around it.

With that framing in mind, the infrastructure decisions that follow become clearer.

Cloud, on-premise, and everything in between

The first question about where your data lives is which hosting model you are operating under. The answer shapes everything that follows.

Software as a Service (SaaS)
SaaS means your HR system is hosted and operated by the vendor. You access it through a browser or mobile application. The vendor manages the servers, the infrastructure, the security, the updates, and the backups. You pay a subscription rather than a license fee, and you do not need to maintain physical hardware.

The security implication of SaaS is significant and frequently underestimated in its favor. A specialized HR software vendor operates their infrastructure as their core business — security, uptime, and data protection are not secondary concerns managed by a generalist IT team, they are existential priorities. The investment required to maintain enterprise-grade infrastructure (redundant data centers, 24-hour physical security, enterprise firewall systems, continuous monitoring, and formal certifications) is spread across thousands of customers rather than borne by a single organization. This typically means a higher baseline of infrastructure security than most individual organizations could justify building and maintaining themselves.

On-premise
On-premise means the software is installed and operated on servers that your organization owns and manages, either in your own facilities or in a data center you contract separately. You control the hardware. You are responsible for its security, its maintenance, its backup, and its recovery.

The appeal of on-premise is control and perceived privacy. The data never leaves your own infrastructure. The practical reality, observed consistently across the region, is that on-premise deployments frequently have weaker security than their SaaS equivalents. Not because the software is less capable, but because enterprise-grade infrastructure requires sustained investment and specialist expertise that most organizations do not maintain as a core competency. Backup processes that look adequate on paper turn out to have never been tested. Disaster recovery plans exist as documents but have not been rehearsed.

Physical security at self-managed server rooms rarely matches what a purpose-built data center provides.

Hybrid Arrangements
Hybrid arrangements, where some components are cloud-hosted and others remain on-premise, add complexity to both security management and compliance, particularly when data moves between environments. Each boundary between on-premise and cloud infrastructure is a point that requires careful attention to encryption in transit, access control, and regulatory compliance.

What a data center actually provides

Understanding where your data lives also means understanding what the hosting environment provides: the physical and operational infrastructure that protects the servers on which your data sits.

A purpose-built enterprise data center is meaningfully different from a server room in an office building. The differences are significant.

Physical security in a serious data center means multiple layers of access control before anyone reaches the server racks — perimeter security, controlled entry points, biometric authentication, logging of every access event, and 24-hour security personnel and CCTV monitoring. Physical access to servers is a significant attack vector that is often overlooked in discussions focused on digital security. A data breach does not require a sophisticated cyberattack if someone can walk out with a hard drive.

Power resilience means uninterruptible power supplies that maintain operations through short outages and generator backup for extended power failures. A data center that loses power loses everything running on it — and for HR systems processing payroll, the timing of that loss can have immediate legal and financial consequences.

Environmental controls — cooling systems, fire suppression, humidity management — protect the physical hardware from the conditions that degrade or destroy it. These are not exciting topics, but hardware failure caused by environmental conditions is a real and preventable cause of data loss.

Network redundancy means multiple independent internet connections from different providers, so that a failure of one connection does not take the system offline. For organizations whose employees rely on an HRIS for leave requests, attendance tracking, and payroll visibility, unplanned downtime is not just an inconvenience — it is an operational failure with real consequences.

Location matters in a region as geographically diverse and disaster-prone as Southeast Asia. A data center located in a flood-prone area, or in a zone with frequent power instability, carries risks that a facility in a lower-risk location does not. For organizations subject to UU PDP’s data residency requirements, this means the choice of in-country hosting is not just a compliance decision but also an infrastructure quality decision — and the two considerations need to be evaluated together.

Backup and disaster recovery: what the terms actually mean

The language around backup and disaster recovery is filled with terms that sound reassuring without being specific. Understanding what they actually mean is essential for evaluating whether your organization (or your vendor) is genuinely protected.

A backup is a copy of your data stored separately from the primary system. The key variables are how frequently backups are created, where they are stored, whether they are encrypted, and whether they have ever been tested by actually restoring from them.

Frequency matters because it determines how much data you can lose in the worst case. A system that backs up once per day means that if the primary system fails at 4pm, you may lose an entire day of transactions — payroll inputs, leave approvals, attendance records, configuration changes. A system with incremental backups every fifteen minutes means the maximum loss is fifteen minutes of data. The difference is significant in any scenario where recovery is needed urgently.

Location matters because a backup stored in the same facility as the primary system is vulnerable to the same disaster. A fire, flood, or ransomware attack that affects the primary data center will also affect a backup stored there. Off-site backups (in a physically separate location, ideally at significant geographic distance) ensure that a single event cannot destroy both the primary data and the recovery copy.

Testing matters because an untested backup is an assumption, not a guarantee. Backup systems fail. Backup files become corrupted. Recovery processes that look straightforward in documentation encounter complications in practice. Organizations that have never actually restored from their backups discover these problems at the worst possible time, during a crisis. Regular recovery testing, documented and reviewed, is the only way to know that the backup will actually work.

Recovery Point Objective (RPO) is the maximum amount of data loss the organization can tolerate, expressed as a time period. An RPO of thirty minutes means that in the event of a failure, the organization accepts losing at most thirty minutes of data. This figure determines how frequently backups must run to meet the requirement.

Recovery Time Objective (RTO) is the maximum time the organization can tolerate being without the system before the outage causes unacceptable business impact. An RTO of four hours means normal operations must be restored within four hours of a failure being declared. This figure determines the investment required in recovery infrastructure. Faster recovery requires more resources.

RPO and RTO should be defined explicitly, not assumed. An organization that has never articulated what data loss or downtime it can tolerate has not actually made a decision — it has simply deferred one that a crisis will eventually force.

A Disaster Recovery Center (DRC) is a secondary infrastructure environment — a separate data center — that can take over operations if the primary environment fails. The DRC holds a continuously synchronized copy of the primary data and has the capacity to run the system independently. The quality of a DRC depends on how current its data is (determined by the synchronization frequency), how quickly it can be activated (the RTO), and whether it has been tested under realistic conditions.

A DRC is not a luxury. For any organization that depends on its HRIS for payroll processing, compliance reporting, or daily HR operations, the absence of a functioning disaster recovery capability is a genuine business continuity risk — one that becomes visible only when it is too late to address it.

Data residency

Data residency refers to the physical location of the servers where your data is stored. It has become a relevant consideration as data privacy laws across Southeast Asia have matured. Most SEA privacy frameworks, including Indonesia’s UU PDP, are not absolute data residency laws — they are accountability frameworks that require organizations to take appropriate measures to protect personal data, regardless of where it sits physically. Cross-border data access is permitted under most frameworks when proper contractual safeguards and data processing agreements are in place.

This places the emphasis less on restricting location outright, and more on understanding how data is handled, protected, and governed when it moves across jurisdictions.

For most organizations using a reputable SaaS HR vendor, the relevant questions are practical in nature: can the vendor tell you where your data is hosted, what safeguards govern access to that data, and can they provide that in writing? A vendor that can answer those questions clearly and provide documentation is demonstrating the kind of accountability these laws are designed to require.

The SaaS advantage in infrastructure: what shared investment enables

One of the most practical arguments for SaaS hosting over on-premise, from an infrastructure security perspective, is the economics of shared investment.

Building and operating a primary data center with physical security, power resilience, environmental controls, and network redundancy (plus a geographically separate disaster recovery center with real-time synchronization) requires sustained capital expenditure and operational expertise. For a single organization, this investment is difficult to justify unless the organization is large enough that its IT function is itself a significant enterprise.

A SaaS vendor hosting thousands of customer environments spreads that investment across all of them. The result is that a mid-sized organization using a SaaS HR platform benefits from infrastructure that would be economically impractical for it to build independently. The data center that holds its employee records has 24-hour physical security, multiple power backup systems, enterprise-grade fire suppression, and a geographically separate disaster recovery facility. Not because the organization could afford to build that, but because the vendor’s business model requires it across all customers.

This does not mean all SaaS vendors provide equivalent infrastructure. The quality of the hosting environment, the specifics of the disaster recovery capability, the data residency arrangements, and the certifications held by the data center are all variables that differ between vendors. The SaaS model creates the conditions for strong infrastructure — it does not guarantee it.

One infrastructure question most organizations forget to ask

Most conversations about HR data infrastructure focus on how data is protected while the vendor relationship is active. Far fewer address what happens to that data when the relationship ends.

Data portability — the ability to extract your complete employee data in a structured, usable format when you leave a vendor — is a practical concern that belongs in the infrastructure conversation, not the contract negotiation that happens years later when you have already decided to move. The question of whether you can get your data out, in what format, how completely, and within what timeframe should be asked before signing, not after.

The scenarios that make this relevant are not unusual. An organization outgrows its current system and needs to migrate to a more capable platform. A vendor is acquired and the product roadmap changes. A contract renewal brings pricing or terms that no longer work. In each case, the organization needs to move its data — and the ease or difficulty of doing so depends entirely on decisions the vendor made about data architecture, and commitments they were or were not willing to make contractually.

Practically, the questions worth asking are: Can we export the complete employee dataset, including historical records, in a standard format such as CSV or XML? Are there limitations on what can be exported, and are any data categories excluded? Is there a fee for data extraction? What is the timeline for receiving a complete export? And once the contract ends, how long does the vendor retain your data before it is deleted?

A vendor confident in the quality of their product and the fairness of their terms will answer these questions directly. Vague answers or resistance to putting export commitments in writing is worth noting before any agreement is signed.

Questions worth asking

Whether you are reviewing your current arrangements or evaluating a new vendor, these questions move the conversation from general assurances to specific, verifiable answers:

• Where, physically, is our HR data stored? The answer should name a country and ideally a facility. “In the cloud” is not an answer.
• Can you explain where our data is hosted and what safeguards govern cross-border access, and can you provide that in writing? 
• Is there a separate disaster recovery facility? Where is it located, and how is data synchronized between the primary and DR environments?
• What is your RPO and RTO? These should be specific figures, not general assurances about “minimal downtime.”
• How frequently are backups created, and where are they stored? Ask specifically about backup encryption and whether backups are stored separately from the primary environment.
• When was the last time a full recovery test was conducted? A vendor that cannot answer this question has not tested their recovery capability recently — which means the RPO and RTO figures they quote are theoretical rather than demonstrated.
• What physical security measures are in place at the data center? The answer should describe specific controls: access logging, biometric authentication, security personnel, CCTV, not general statements about the facility being “secure.”
• What is your documented uptime SLA, and what is your actual historical uptime? The SLA is a contractual commitment; the historical figure is evidence of whether that commitment is being met.
• If we decided to leave your platform, what would the data extraction process look like: format, completeness, timeline, and cost? Can that be documented in the agreement? 

If the answers to these questions are vague, undocumented, or met with reassurances rather than specifics, that is meaningful information about the vendor’s infrastructure investment and transparency.

The question “where is your data?” sounds simple. The answer — when fully traced through hosting model, data residency, physical infrastructure, backup frequency, disaster recovery capability, and recovery testing — is rarely as straightforward as “in the cloud.” Understanding it is not an IT exercise. It is a governance responsibility that sits with the people accountable for employee data and organizational continuity.

And like the earlier topics in this series, the gap is rarely in the system itself. It lies in how completely the organization understands and manages the environment around it.

This is the fourth article in a series on HR data security and privacy for organizations operating in Southeast Asia. The series is written from the perspective of DataOn, the team behind SunFish HRIS, a vendor in this market with 25 years of operational experience across the region.