Where the Employee’s Information Sits

A reasonable question that takes eight seconds to ask and three organisations to answer. Three places information ends up, what a dashboard does not show, and the one page that answers most of it.

Michael Rodriguez Michael Rodriguez 24 min read
Where the Employee's Information Sits

TL;DR

  • The core question: which organisation holds what about each person, and where.
  • When it does not matter yet: it always matters, but the work scales with headcount.
  • What to establish: the actual answer, in writing, rather than an assumption.
  • How arrangements differ: by what each party holds and what you can see.
  • Decision rule: ask during evaluation, because asking afterwards is harder.
  • Outcome to expect: knowing where things are before you need to know.

The Question Nobody Asks Until They Need To

Somebody asks a reasonable question. They want to know what's held about them, or they want something corrected, or they've left and want to understand what happens next. It arrives in a Slack message and it takes about eight seconds to answer, in theory.

Then you try to answer it. Their details are in a provider's system. Some of it is also in your own tools because somebody exported a spreadsheet nine months ago. There may be a payroll system involved that you've never logged into. And the honest answer to where their information sits is that you'd need to ask, which is not what anybody wanted to hear.

What makes that answer uncomfortable is not the delay. It's that the person asking now knows something they didn't know before, which is that their employer does not have a clear picture of where their information lives. That's a small thing and it lands, because it's their details and the question was not complicated.

The reframe: this isn't a question about systems. It's a question about which organisation holds what, and the reason it's hard is that these arrangements split that across at least two parties by design, and nobody wrote down where the line falls.

The split is not a flaw. It's what the arrangement is: a provider runs the employment systems in a country where you have none, which necessarily means they hold most of the records. The flaw is only that the line between what they hold and what you hold is never stated anywhere, and so it gets discovered one question at a time, usually by somebody who needed an answer today.

And the discovery is always partial. You find out where one thing lives because somebody asked about that thing. The next question is about something else and the process repeats. Organisations can run for years this way, answering each question individually, without ever producing the picture that would have answered all of them.

Free Weekly Briefing Stay ahead of what's changing in HR and people ops.

Join 4,200+ leaders getting practical insights every week — no fluff, just signal.

Join Free →

That's worth separating from the technical question, which is the one that tends to get asked instead. Which platform, which region, which integration: all answerable, all secondary. The question underneath is who holds what, who can see it, and who the person asks when they want something.

And the reason to settle it early is simple. Asking during an evaluation, when a provider wants your business, produces different answers than asking afterwards, when it's a support ticket competing with everything else in the queue.

That isn't cynicism about providers. It's about who's on the other end. During an evaluation you're talking to somebody whose job is to answer your questions thoroughly and who has access to people who know. Afterwards you're talking to a support function whose job is to resolve tickets, and a question about what exists in their systems that you can't see is not a ticket-shaped question.

The same asymmetry applies to written answers. Before a signature, a request to put something in writing is a normal part of a procurement conversation. After one, it reads as an escalation, which changes how it gets handled and how long it takes.

One boundary before anything else. Nothing here states any data protection requirement, names any regulation or regulator, or says what anybody must do. Those differ by jurisdiction and by circumstance and they're a question for somebody qualified in each place you operate. What follows is about knowing where things are, which is a prerequisite for that conversation rather than a substitute for it.

When You Do Not Need to Do Anything About This

One person, recently started, nothing unusual. The question still applies but the practical burden is small. Know who to ask and move on.

A handful of people, arrangement working. Worth thirty minutes writing down where things sit, once, so the answer exists when somebody asks.

Several countries, growing. Now it's real work, because the answer may differ by country and the assumption that it doesn't is the thing that catches people.

Somebody has asked a specific question. Then it's immediate, and the right move is asking the provider directly rather than reconstructing an answer from what you think you know.

The fourth case deserves emphasis because reconstructing is the instinct. Somebody asks, you don't want to look unprepared, so you assemble an answer from what seems likely. The answer is probably close. Probably close is the wrong standard for a question about an individual's own records, and the provider can give you the actual answer in an afternoon.

Five Questions This Reader Asks at 11pm

Who actually holds what? Split between you and a provider, and the split isn't obvious from the outside. Ask for it in writing rather than inferring it from which system you happen to log into.

What can I see? Usually less than you expect, and what's visible in a dashboard isn't the same as what's held. Those are two different questions and providers answer them differently.

Where does it physically sit? A reasonable question with a specific answer that providers can give, and one that matters more to some organisations than others depending on where they operate.

What happens when somebody leaves? Something does, on both sides, and knowing what before somebody leaves is considerably easier than establishing it afterwards.

Who does the person ask? The one that matters most in practice. If an individual wants to know something about their own information, they need a name, not a diagram.

How much of this is our responsibility? Some of it, and which parts differ by jurisdiction and by circumstance, which makes it a question for somebody qualified in each place you operate rather than one to settle from an article. What's true everywhere is that you can't work out your own position without first knowing where things sit, which is why the mapping comes before the advice rather than after it.

Are we holding more than we think? Almost certainly, and the gap is usually in your own tools rather than the provider's. Every export was individually reasonable and nobody was counting.

Three Places Information Ends Up

With the provider, in their systems

The primary location and the one most of it sits in. Employment records, payroll details, whatever documents were signed, whatever gets collected in the course of the arrangement.

When it's right to think of this as the main answer: almost always, because it's where the working systems are and where the day-to-day activity happens.

Where it falls short is visibility. You don't run the system, you see what the dashboard exposes, and the gap between what's held and what's shown is where most surprises live. Ask specifically what exists that you can't see, and get the answer in writing.

The dashboard problem is worth dwelling on because it's so easy to miss. An interface showing employment records, payroll history, documents and contact details presents as comprehensive, and there is nothing in it that says otherwise. Nothing is being concealed. It's simply that a product surfaces what the product needs to surface, and the set of things held is larger than the set of things displayed for entirely ordinary reasons.

Which means the question has to come from you, phrased specifically. Not is this everything, which invites a reasonable yes, but what exists in your systems about our people that does not appear in this interface.

With you, in your own tools

The copies. A spreadsheet somebody exported, a directory entry, records in whatever you use for your own people, details in an expenses tool or a project system.

When this is right: it's largely unavoidable, because people need to work with colleagues and that requires knowing things about them.

A colleague needs a contact number. A manager needs to know who reports to whom. Finance needs something for a budget line. Each of those produces a copy somewhere, and each copy was made for a reason that would survive any audit individually.

Where it falls short is that it accumulates without anybody deciding it should. Exports get made for a reason and then stay, and an organisation ends up holding more than it realises in places nobody catalogued. That's the part you control and the part most often ignored, because the provider's systems feel like the interesting question.

The pattern is consistent enough to predict. A spreadsheet made for a headcount exercise, still in a shared drive. A directory entry with details somebody typed in manually. An onboarding checklist in a project tool. A benefits question answered over email eighteen months ago with an attachment. None of it was a decision and all of it is yours.

The fix is not a policy. It's an afternoon with a list of your own tools, asking of each one whether it holds anything about people engaged through the arrangement, and writing down what you find.

With somebody neither of you chose

Whatever sits underneath. Payroll processing, a benefits administrator, a local partner in a country where coverage runs through somebody else, the infrastructure any of them use.

When it's right to look at this: when you operate somewhere that makes it matter, or when your own obligations require you to know.

Where it falls short is depth. You can ask and a provider can usually answer one layer down, but the chain continues past the point where anybody has a complete picture. Ask, expect a reasonable answer about the layer beneath, and treat total visibility as unrealistic rather than as a failure.

The practical version of that: ask who else is involved in delivering the arrangement in each country, and expect a straight answer. Ask what sits beneath them and expect something less specific. That's not evasion, it's the ordinary shape of any supply chain, and an organisation claiming complete visibility several layers down is making a claim worth examining rather than one worth trusting.

Five Diagnostic Questions You Can Self-Assess Against

Could you answer where a specific person's records sit, today? Without asking anybody. If not, that's the whole gap, and it's a thirty-minute fix at small scale.

Do you know what you hold yourself? The exports, the spreadsheets, the copies in your own tools. Most organisations underestimate this and it's the half they can actually do something about.

Does the answer differ by country? It may. Assuming it doesn't is how organisations end up with a picture that's accurate somewhere and wrong elsewhere.

Who would a person ask? Name them. If the answer is a process rather than a person, the person asking will find that out and it won't go well.

Have you asked, or assumed? The difference between a written answer from a provider and a reasonable inference is the difference between knowing and guessing.

The fifth question is the one to be honest about, because inference here is unusually convincing. You know how these arrangements generally work, you know what systems exist, and the picture you construct will be mostly right. Mostly right is fine for a planning conversation and not fine for an answer given to a specific person about their own records, which is where this always eventually lands.

What to Establish, and When

What to establish Ask whom When Why it is hard later
What the provider holds The provider, in writing During evaluation Support queue, not sales
What you can see The provider, with a demo During evaluation Dashboards look complete
Where it physically sits The provider During evaluation Rarely volunteered
Who sits underneath them The provider During evaluation Answers thin with depth
What you hold yourself Yourselves Any time Nobody owns the question
What happens when somebody leaves The provider Before anybody does Urgent when it is live
Who a person asks Both of you Before anybody asks A name, not a process
Whether it differs by country The provider, per country Before country two Assumed uniform

The first column is deliberately phrased as things to establish rather than things to worry about. Most of it is answerable in a short call, and almost all of the difficulty comes from asking at the wrong moment rather than from the questions being hard.

The third column is doing the real work in that table. Almost every row says during evaluation, and that's not a coincidence: this is a subject where the information is freely available right up until the point you've committed, after which it becomes a request rather than a conversation.

The fifth row is the one you own entirely. No provider can tell you what's in your own spreadsheets, and it's the part that grows quietly because every export was individually reasonable.

The eighth row is the one that gets deferred until there is a second country, at which point it gets answered for the second country only and the first is assumed to match. Ask about both, at the same time, and you will either confirm they match or find out early that they don't.

Where This Gets Complicated

More than one country. The answer may differ between them, which turns one question into several. Ask per country rather than generally, and expect at least one to be different in a way nobody predicted.

The reason to expect divergence rather than hope for uniformity is that a provider's arrangements in each country were assembled separately, often at different times and sometimes with different partners. Consistency across them is a thing a provider works at rather than a thing that happens by default.

Coverage that runs through somebody else. Where a provider works with a local partner, there's an additional party in the picture. That's normal and worth knowing about rather than worth avoiding.

Your own accumulation. The copies you hold, which nobody catalogued and which grow with each export. The only part of this fully within your control and the part most often left.

Somebody leaving. Things change on both sides and the question becomes specific rather than general. Much easier to have established beforehand.

A direct request from a person. The moment all of this stops being abstract. Somebody wants to know something about themselves and the quality of your answer reflects the work done before they asked.

And it reflects it precisely. Nothing about a good answer here is improvisable under time pressure, which means the response somebody gets is essentially a readout of whether anybody wrote anything down in the preceding year.

Scale arriving faster than process. Five people is a conversation. Thirty across four countries is a system, and the transition between those tends to happen without anybody noticing until something needs answering quickly.

The transition point is worth naming because it has no alarm attached. Nothing breaks when an organisation crosses from a size where one person remembers everything to a size where nobody does. The knowledge just quietly stops being complete, and the first sign is somebody asking a question that used to take a minute and now takes a week.

The Decision Table

Situation Scale Setup Primary Pain Recommended Starting Point
One person, just started 1 New None yet Know who to ask
Small team, one country 2-5 Live Nothing written down Thirty minutes, write it down
Growing, several countries 10+ Live Assumed uniform Ask per country
Currently evaluating Any Pre-signature Best moment, easily missed Ask now, get it written
Exports accumulating Any Live Nobody owns it Audit your own side
Somebody has asked Any Live Needs an answer today Ask the provider directly
Somebody leaving Any Live Specific, time-bound Establish before, not during
Arrangement ending Any Ending Two sides, both changing Part of the transition plan
Coverage via a partner Any Live Extra party in the picture Ask one layer down

The fourth row is the one worth acting on if it applies, because the difference in answer quality between a pre-signature question and a post-signature support ticket is larger than it should be and entirely predictable.

The sixth row is where most organisations meet this subject for the first time, which is the wrong order but the common one. If you're there now, the fastest route is asking the provider rather than assembling an answer from what you believe to be true.

The fifth row is the one with the best return for the effort involved. Auditing your own side needs no cooperation from anybody, costs an afternoon, and answers the half of the question that no provider could answer for you. It is also, consistently, the half that turns out larger than expected.

What Good Looks Like

One page, written down. What sits where, who holds what, who to ask. Not a policy document, a page. It takes half an hour and it answers most of what will ever be asked.

A named person on each side. Yours and theirs. When somebody has a question about their own information, the answer should be a name.

Asked, not assumed. Written answers from the provider, obtained during evaluation where possible. An assumption that turns out to be right is still an assumption.

The useful discipline is marking the page itself. Next to each line, note whether it came from a written answer or from inference. It takes a few seconds per line and it tells whoever reads it later exactly which parts they can rely on and which parts need checking before being repeated to anybody.

Your own side audited. What you hold, in what tools, from which export. Nobody else can do this and it's the half that grows on its own.

Per country, where you have several. One answer applied everywhere is a plan that works in one place.

Worth noting that this is the item most likely to be skipped on cost grounds, since asking per country means asking several times and each answer takes effort to obtain. It's also the item where being wrong is least visible until somebody in the country you didn't check asks something specific.

Reviewed when something changes. New country, new provider, new tool, significant growth. Not a schedule, a trigger list.

The trigger list matters more than a review cadence because the things that invalidate the page are events rather than time passing. A page written accurately in March is still accurate in September unless something specific happened, and if something specific did happen, waiting for a quarterly review is the wrong response to it.

The list is short on purpose. Most of the failure here isn't inadequate process, it's that nobody wrote anything down and the knowledge lived in one person's head until they were unavailable on the day somebody asked.

There's a temptation to turn this into something more formal, and it's worth resisting at small scale. A policy nobody reads answers nothing. A page that says where things are, who holds what and who to ask answers almost everything, and it has the considerable advantage of being short enough that somebody will actually look at it when they need to.

Where These Arrangements Go Wrong

The failure How it shows up What would have to change
Nothing written down A simple question takes days, not minutes One page, once
Assumed uniform across countries Right somewhere, wrong elsewhere Ask per country
Own side never audited More held than anybody realised Audit the exports
Dashboard mistaken for the whole picture Surprise about what exists Ask what is not shown
No named contact A person routed through a process Name somebody, both sides
Asked after signature Slower, thinner answers Ask during evaluation
One person holds the knowledge Fine until they are away Write it down, not up

The fourth row is the most common and the least obvious. A dashboard showing employment records, payroll history and documents looks complete, and there's no prompt anywhere in the interface suggesting otherwise. The question has to be asked deliberately because nothing in the product will ask it for you.

The second row has a similar quality. Nothing tells you that a country differs, because a country that differs looks exactly like a country that doesn't until somebody asks a question specific enough to expose it.

The fifth row is the one that shows up as a bad experience for a specific person rather than as a process problem. Somebody asking about their own information and being handed a ticket number has learned something about how the organisation thinks of them, and that impression is difficult to undo later.

The seventh row is the failure that only appears when somebody is on holiday. One person who knows where everything sits is a working arrangement right up to the week they're unreachable, and it fails at exactly the moment nobody can wait. Writing it down is not bureaucracy, it's the difference between knowledge and a dependency on an individual.

Questions to Ask Before You Commit

What a Person Might Reasonably Ask

What they want Who can answer it How long it should take What makes it slow
What is held about me The provider, usually Days Nobody knows who to ask
Please correct something The provider, usually Days Unclear route
Who else can see this Both of you Same day Never established
What happens now I have left The provider, and you Days Asked after the fact
Where is it kept The provider Days Not asked during evaluation
Who do I talk to You Immediately No named person

The last row is the one that shapes how every other row feels. An individual with a name to contact experiences a functioning arrangement even when an answer takes a few days. An individual routed into a queue experiences the opposite, regardless of how quickly the answer arrives.

The third row is the one organisations least expect and it's a fair question. Somebody engaged this way has details sitting with an organisation they've never chosen and one they work for, and asking who can see what is entirely reasonable. Having an answer ready is better than assembling one while they wait.

On holding. What exists about each person, and where? A bad answer is in the platform.

On visibility. What is held that we cannot see? A bad answer is everything is visible.

On location. Where does it physically sit, per country? A bad answer is the cloud.

On depth. Who sits underneath you? A bad answer is nobody.

On leaving. What changes when somebody goes? A bad answer is it is handled.

On contact. Who does an individual ask? A bad answer is support.

On change. What happens if you change a subprocessor or a country partner? A bad answer is we will let you know.

On writing. Can we have that in writing? A bad answer is any hesitation at all.

What Getting This Wrong Costs

The first cost is a simple question taking days. Somebody wants to know something ordinary about themselves, the answer requires asking two organisations, and what should have been a short reply becomes an exercise in finding out. The cost isn't the delay, it's that the person now knows the organisation doesn't have a clear picture of where their information sits, which is not a reassuring thing to learn about your employer.

The second cost is your own accumulation, unnoticed. Every export was reasonable at the time. Nobody decided the organisation should hold copies of employment details across four tools; it happened through a series of individually sensible decisions and nobody was watching the total. It's the half within your control and the half least often examined, because attention goes to the provider's systems, which feel like the more serious question.

And the accumulation compounds with the number of tools rather than the number of people. An organisation with eight people engaged this way and fifteen internal systems has a larger problem than one with thirty people and four, which is not the intuition most teams start with. The relevant count is how many places a copy could live, not how many people there are.

The third cost lands when something else is already happening. An arrangement is ending, somebody is leaving, or a question has arrived with a deadline attached, and the work of establishing where things sit now has to happen under pressure alongside everything else. That work is the same work either way. Done calmly it's a short call. Done urgently it's a bad week.

The pattern repeats across everything in this subject and it's the single most useful thing to take from it. None of these questions are hard. All of them are answerable. The only variable is whether they're answered at a moment of your choosing or at a moment somebody else chose, and the difference in effort between those two is roughly an afternoon against a fortnight.

So do three things. Write down where things sit, once, on one page. Audit your own side, because nobody else will. And name a person on each side so that anybody asking about their own information gets a human being rather than a queue.

When You Are Ready to Go Further

Start with the one page, because it's the highest return per minute of anything in this piece. What the provider holds, what you hold, what you can see, who to ask. Half an hour, written down somewhere findable, updated when something changes. Most of what will ever be asked is answered by that page.

Findable is doing more work in that sentence than it looks. A page nobody can locate is a page that doesn't exist on the day it matters, and these things have a habit of ending up in whichever tool the person who wrote them happened to prefer.

Then audit your own side properly. Every export, every spreadsheet, every tool holding details about people engaged this way. It's the half nobody looks at, it grows without decisions, and it's entirely yours to fix. Expect the total to be larger than the estimate.

A workable method: list your own systems first, before looking at any of them, then go through the list one at a time asking whether that system holds anything about people engaged through the arrangement. Starting from the systems rather than from the people is what catches the tools nobody associates with employment records, which is where the surprises usually are.

Finally, if you're still evaluating, ask now. What's held, what's visible, where it sits, who's underneath, what happens when somebody leaves. Get the answers in writing while somebody wants your business, because the same questions asked in eighteen months go into a support queue and come back shorter.

HROpsLab publishes independent comparison work across HR tooling and global employment. We sell nothing, we take no vendor money, and we publish no paid placements. If the next step is comparing how providers in this space actually answer these questions, our comparison work is one place to start.


Frequently Asked Questions

Who holds employee data in an employer of record arrangement?

It's split between you and the provider, and the split isn't obvious from the outside, which is why it's worth asking for in writing rather than inferring. The provider holds the working systems: employment records, payroll details, signed documents, whatever accumulates in the course of the arrangement. You hold whatever you've copied into your own tools, which is usually more than anybody estimates. Both halves are real and only one of them is anybody's stated responsibility.

Can we see everything the provider holds?

Generally less than you'd expect, and what a dashboard shows isn't the same as what exists. That's not a criticism of any provider, it's how systems work, but it means the question has to be asked deliberately because nothing in the interface will prompt it. Ask specifically what's held that isn't visible to you, ask during evaluation rather than afterwards, and get the answer in a form you can refer back to.

Where is the data physically stored?

Providers can answer this and usually will if asked directly, and the answer may differ by country. How much it matters depends on where you operate and what your own obligations are, which is a question for somebody qualified in each place rather than something to settle from a general article. Worth asking during evaluation, since it's rarely volunteered and it's the kind of question that gets a thinner answer once it's a support ticket.

What about our own copies?

That's the half most organisations overlook, and it's entirely within your control. Exports into spreadsheets, entries in directories, details in expenses or project tools. Each one was reasonable when it was made and nobody was tracking the total. An audit of your own side takes an afternoon, costs nothing, and usually turns up more than the estimate, which is exactly why it's worth doing before somebody asks a question that requires knowing.

What happens to information when somebody leaves?

Something changes on both sides, and what changes is worth establishing before anybody leaves rather than during. Ask the provider what happens on their side and settle what happens on yours, since your own copies are the part you control. The general point holds throughout this subject: every one of these questions is a short conversation when nothing is urgent and a difficult week when something is.

Who does the employee ask about their own information?

Somebody by name, on one side or the other, and preferably somebody they've met. A person asking about their own details and receiving a ticket number has learned something about how much thought went into their part of the arrangement. Decide who it is, tell people, and make sure that person actually knows where things sit rather than being a routing step towards somebody who does.

Does the answer differ between countries?

It may, and assuming it doesn't is the mistake that catches organisations operating in several places. A picture assembled from one country and applied everywhere is accurate somewhere and wrong elsewhere, and the discovery usually arrives when somebody in the country you didn't ask about has a specific question. Ask per country, before you're in the second country rather than after, and expect at least one answer to differ in a way nobody predicted.

What should we ask before signing?

What's held about each person and where, what exists that we can't see, where it physically sits per country, who sits underneath the provider, what happens when somebody leaves, and who an individual asks about their own information. Six questions, answerable in one call, and all of them get better answers before a signature than after one. Write down what you're told, because eighteen months later nobody will remember who said what.

The question takes eight seconds to ask. Make sure it takes about that long to answer.

Share on X Share on LinkedIn

What to do next?

Explore More Articles

Dig deeper into HR Ops strategy, tools, and workflows built for real teams.

Browse the blog →
Join the HROpsLab Community

Connect with People Ops practitioners sharing real workflows, tools, and challenges.

Join now →