Client Data Privacy When Agencies Outsource WordPress Work

The moment you give an outside developer an administrator login to a client’s WordPress site, you have shared more than code. That login opens form submissions with names and phone numbers, WooCommerce orders with home addresses, user accounts, newsletter lists and sometimes uploaded files that customers assumed only the business would see. Most agencies hand over that access without a second thought, because the job is a plugin fix and the data feels incidental. It is not incidental to the people it belongs to.

This post is about handling client and customer data sensibly when a remote partner is part of your team: what data is actually on a typical site, how to limit what a partner can see, what to agree in writing, and what to do if something goes wrong.

General information, not legal advice. Privacy rules depend on where your clients and their customers are, what kind of data is involved and what the client’s own contracts say. For anything specific, your client should speak to their attorney, and so should you about your own agreements.

Why this matters more than it seems

There are three parties with an interest here, and each has something different at stake.

• The client’s customers gave their details to a business they trust, not to the business’s web contractors.
• The client is usually the one answerable for that data, under privacy laws and under any promises in their own privacy policy.
• The agency chose who else got access. If the partner mishandles data, the client will hold the agency responsible, whatever the paperwork says.

The legal picture in the US is a patchwork. There is no single federal law covering all consumer data in the way some other countries have one; instead there are federal rules for particular sectors and kinds of data, and a growing number of states with their own consumer privacy laws. If a client has customers in the EU or UK, those regions’ data protection rules may apply to them as well. You do not need to master all of this, but you should assume that at least one set of rules applies to most client sites, and behave accordingly.

Know what data the site actually holds

You cannot protect what you have not noticed. For each client, take a few minutes to list where personal data lives on the site. Common places:

• Form entries stored in the database by the form plugin, often kept forever by default.
• WooCommerce orders and customer accounts: names, addresses, emails, phone numbers, order history.
• WordPress user accounts, including subscribers and members.
• Comments, with email addresses and IP addresses.
• Uploaded files from application forms, quote requests or support tickets.
• Plugin logs: security, email and activity logs often record IP addresses, emails and usernames.
• Backups and staging copies, which contain everything above, again.
• Connected services: CRM, newsletter and payment platforms the site sends data to.

Write this down in the client’s site notes. It tells you, and any partner, which areas need care. It also tells you which sites are higher risk: a site with health, financial or children’s information deserves stricter handling than a brochure site with a single contact form.

Give a partner the least access that does the job

The simplest privacy control is not giving access in the first place. Before you share anything, ask what the task genuinely needs.

Separate accounts, always

Create a named account for each person at the partner, never a shared “developer” login and never the client’s own account. Named accounts can be removed individually and show up in activity logs, so you know who did what. Our post on sharing client logins without losing track covers the mechanics, including password managers and revoking access when work ends.

Use roles, not just administrator

Plenty of tasks do not need full administrator rights. Content edits fit an editor role. Some store tasks fit the shop manager role WooCommerce adds. Where a plugin offers finer permissions, use them. WordPress’s built-in roles are explained in our post on giving each user only the access they need.

Prefer staging with cleaned data

For development and testing, a staging copy with customer data removed or replaced is often enough. Some tools and hosts can strip or scramble personal data when copying a site; where that is not available, deleting order and form data from a staging copy before handing it over is a reasonable manual step. A partner who never sees real customer records cannot leak them.

Limit server and database access

SSH, SFTP and database access expose everything at once. Give them only when the task requires it, to named users where possible, and remove them afterwards.

Time-box access

Access granted for a job should end with the job. Put a reminder in your ticket system to remove accounts once work is signed off, or set expiry dates where the tool allows.

Questions to ask a partner before sharing data

Whether you are evaluating a new partner or reviewing an existing one, these questions show how seriously they take data. Good partners will have answers ready.

1. Who on your team will have access to client sites, and how do you remove access when someone leaves?
2. Do you download databases or backups to your own computers? If so, how are they stored and when are they deleted?
3. Do you use password managers, and is two-factor authentication on for your own accounts?
4. Will you sign a confidentiality agreement, and are you willing to follow data handling terms we pass on from our clients?
5. If you notice something that looks like a breach, who do you tell and how quickly do you raise it?
6. Do you use any outside tools or services that would receive client data while you work?
7. Where is your team located? Some client contracts restrict where data can be accessed from, so we need to know.

The last question is not a trap. Plenty of capable teams work from outside the US, ours included. But if a client’s contract says customer data may not leave the country, that is something you need to know before you assign the work, not after.

What to put in writing

A confidentiality agreement is the start, not the whole of it. The sibling post on what an agency’s NDA and partner agreement should cover goes through the main clauses. For data specifically, make sure your agreement with the partner, and ideally your agreement with the client, deals with:

• That the partner handles personal data only to carry out the work you assign, and not for any other purpose.
• That the partner keeps access limited to the people who need it.
• That copies of data, including database exports and backups, are deleted when no longer needed for the job.
• That the partner tells you promptly if they suspect a security problem or data exposure.
• That the partner does not pass data to other parties or tools without your agreement.
• That the terms survive the end of the relationship.

Some clients will ask you to sign their own data processing terms, and those may require you to pass the same obligations down to any partner. Read them before you agree, and check that your partner agreement actually covers what you are promising.

Day-to-day habits that reduce exposure

• Do not paste customer details into chat threads or tickets. Refer to an order number or a user ID instead.
• When debugging a form, use test submissions rather than real enquiries where you can.
• Take screenshots that crop out personal information, or blur it, before sharing.
• Set form plugins and logs to keep entries for a sensible period rather than forever, with the client’s agreement.
• Remove old staging sites and downloaded backups when a project closes.
• Check that privacy settings, such as a cookie notice or consent options, are not quietly broken by updates.

Requests from customers

Depending on where they live and which rules apply, a client’s customers may have the right to ask what data is held about them, or to have it deleted. Those requests go to the client, but the agency is often asked to carry them out. WordPress includes export and erase tools for personal data, which help with the parts stored in WordPress itself; data in plugins, logs, backups and connected services may need separate steps. Our post on handling a customer’s request to delete their data walks through the practical side.

If something goes wrong

Suppose a partner reports that a database export was left somewhere it should not have been, or a site is compromised and customer data may have been reached. The order of steps matters:

1. Contain it: remove the exposed file, change credentials, close the access route.
2. Record what happened, when, and what data was involved, while it is fresh.
3. Tell the client promptly and factually. It is their data, and they decide what happens next.
4. Let the client take legal advice on whether customers or authorities need to be told. Do not contact the client’s customers yourself unless asked.

Our post on who to notify after a website breach goes further into that conversation. Data handling is one piece of a larger arrangement, and the pillar page on how US agencies hand off WordPress work puts it in context.

If you are looking for a partner that works with named accounts, keeps data access to what the job needs and will sign an NDA, our page on white label WordPress security describes how we look after client sites behind your agency.