Giving a client access without giving them everything

You give a client the minimum access they need — role-based permissions, separate environments and an audit trail — while keeping production root credentials, server admin and billing controls in your own hands. Client access permissions are that balance: trust, verified at the level of individual actions, and revocable in one place.

Key Takeaways

• Start from what the client needs to do, not what the platform allows.
• Use separate accounts, roles or projects so access is scoped and revocable.
• Never share root, administrator or billing credentials with a client.
• Grant read-only by default, then add write access one step at a time.
• Turn on audit logging before you grant anything, not after something breaks.
• Plan revocation at the same time you plan the grant — offboarding is part of the design.
• Prefer each platform's native permission system over one shared login.

What does "client access permissions" actually cover?

Client access permissions define what a client can see and change across the systems you run for them: the code repository, the WordPress or app backend, the hosting control panel, analytics, DNS and domain settings. The principle is least privilege — each account gets the smallest set of rights that lets the client do their job, nothing more. A client reviewing copy does not need the ability to install a plugin.

In practice this spans several different tools at once. A WordPress build has its own user roles: Administrator, Editor, Author, Contributor and Subscriber, plus WooCommerce roles like Shop Manager. A GitHub or GitLab repository has Admin, Write, Read and Triage levels. Hosting panels such as cPanel, Plesk or a cloud provider console each have their own permission model. You cannot set this once and be done; you set it per system, per person, per environment.

Why does getting this wrong cost you more than the project itself?

A client with administrator access can delete a database, change DNS records, or push an untested change to production. The failure is not hypothetical; one mistaken click on a hosting panel can take a site offline for hours. Recovery means restoring backups, checking logs, and explaining to the client why their own team caused the outage — while the business loses orders by the minute.

The harder cost is reputational. If a client's staff member accidentally breaks something and then blames the agency for "not protecting them", you are now defending a decision you made casually. Scoping access is partly self-protection. A written record of who was granted what, and why, turns a blame conversation into a simple log review.

When do you actually need to grant access?

Give access only when the client's role requires it: approving content, uploading products, viewing analytics, or accepting a handover at the end of a project. A stakeholder who only needs to see progress does not need a login to production. If a request feels vague, ask what action they need to perform, then scope to that action alone.

There are also times when no direct access is the right answer. A founder who wants to "have a look around" can be served by a recorded walkthrough, a staging link, or a scheduled report. That keeps production untouched and gives you a reason to talk through what they are seeing, which is often what they actually wanted.

How does scoped client access work in practice?

You create separate accounts, roles or projects per person and per environment. On WordPress that means Editor instead of Administrator; on GitHub a Read role instead of Admin; on AWS an IAM policy scoped to one bucket and one action. Each system has a native permission model — use it rather than sharing one password across the team.

Environment separation does a lot of the work for you. Grant the client broad rights on a staging or development environment where mistakes are cheap, and keep production locked down. That way they can experiment, upload content and click around without the blast radius of a live database. You can read more about how that separation maps to hosting tiers in our guide to shared hosting versus VPS versus cloud.

Step-by-step: how to set up client access permissions safely

Start with an inventory of every system the project touches, then map each client to the actions they actually perform. Create individual accounts, assign the lowest role that fits, test the access as that user, and record the grant in an access register so you can review and revoke it later. Here is the sequence we follow:

1. Inventory the surfaces. List every system the client could touch: repository, CMS backend, hosting panel, analytics, DNS, file storage, email.
2. Write down what each person needs to do. "Review pages" is a read action. "Publish blog posts" is a write action on one content type. Be specific.
3. Create an individual account for each person. No shared logins, no "[email protected]" used by five people. Individual accounts are the only way to revoke one person without cutting off everyone.
4. Assign the lowest role that satisfies the need. Start read-only. If they need to write, scope the write to the smallest area possible: one site, one branch, one bucket, one content type.
5. Test the access as that user. Log in with their account, or impersonate the role, and perform the expected actions. Then try one action they should not be able to do and confirm it is blocked.
6. Record the grant. Note who was granted what, on which system, on what date, and who approved it. A simple register in a shared document is enough for most teams.
7. Set a review date. Quarterly, or whenever the client's team changes. Access that is not reviewed tends to accumulate until someone has more rights than their job needs.

If you are managing access on AWS, a scoped policy looks like the example below. It allows one action — reading objects — on one staging bucket, nothing else. The resource ARN is specific, so the policy cannot leak into production.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::client-staging-assets/*"
    }
  ]
}

You can see the full IAM policy reference in the AWS IAM documentation, and GitHub's repository role definitions in the GitHub access docs. Both are worth bookmarking because the exact role names shift between plans.

What configuration actually matters?

The configuration that matters is the one that survives a staff change: named individual accounts, group memberships, environment separation, and audit logging switched on. A single shared "client" login with a common password is the single biggest access risk we see, and it is also the hardest to revoke cleanly because you cannot tell who did what.

Group membership beats per-person tweaks. When a new client contact joins, you add them to the "client-editors" group rather than re-deriving their rights from memory. When they leave, one removal from the group revokes everything at once. This matters more than the exact role names, because group thinking forces you to define access by job function, not by individual favour.

How do you verify the access is right?

Log in as the client's account and try the three or four actions they were granted, then confirm what they cannot do. Check the audit log to see the test was recorded. Repeat this review before a handover, after any role change, and when someone leaves the client's team. Verification is not a one-time step; it is a recurring discipline.

A useful check is the "can they deploy?" test. Open the client's account and ask whether they can reach a deploy button, a production environment toggle, or a destructive action like emptying a database table. If the answer is yes and the client does not deploy as part of their job, the role is too broad. Walk it back and re-test. This single test catches more over-granting than a full policy review.

What breaks in production, and how do you debug it?

The common failure modes are a client locked out of a system they need, or a client with too much access deleting something. The first check is the account's role and group membership, then the audit log to see the attempted action and the error. Revocation gaps usually come from a forgotten third-party integration that still holds a token.

When a client reports being locked out, do not immediately widen their role. First confirm what they are trying to do and which system rejected them. The audit log will usually show the denied action and the reason. More often than not, the fix is adding a single permission to a group, not promoting them to admin. When you do change a role, note it in the register and tell them what changed. The same discipline applies when a project ends — see our offboarding checklist for revoking system access.

What does this cost in time and ongoing care?

Scoped client access costs engineer time, not licence fees. The initial setup is a few hours across all the systems in play. The recurring cost is the review you run quarterly and whenever the client's team changes. Skipping the review feels cheaper until you spend a day restoring a production database after a well-meaning client deletes a table.

The operational overhead sits with whoever owns the relationship. If that is your team, the register and the review cadence are part of the retainer, not an extra. If the client has an internal IT person, you can hand the register over and let them run the reviews. What you should not do is grant access and then forget about it. Our team can help you set up the roles and the review process as part of ongoing website maintenance.

What are the security considerations?

Shared credentials, missing MFA, and admin roles on a live site are the three risks that appear in almost every access review. Treat client accounts as external accounts: enforce strong passwords, require multi-factor authentication on anything that can reach production, and never email a password in plain text.

A shared password is not access control. It is a rumour with a login form. If two people use the same account, you cannot revoke one without revoking both, and you cannot trace an action to a person.

Also check what connected apps and API keys the client has accumulated. A marketing tool that posts to the site on the client's behalf holds a token that survives the client's own password reset. Revoke the obvious logins, then go hunting for the integrations you forgot about.

What mistakes do teams make?

The mistake we see most often is granting Administrator "just to get the client unblocked" and never walking it back. Second is storing every client's credentials in a spreadsheet that no one owns. Third is revoking the obvious logins but leaving a connected app or API key active. Each of these feels fine on the day it happens and bites months later.

Another common one is treating all clients the same. A client who pays for a managed service and never touches the backend needs different rights from a client with an in-house developer who commits directly. Scope per relationship, not per template. The safer default is the managed-service client: view-only where possible, and a change request process for everything else.

A concrete scenario: handing over a staging site

A client asks for access to review a new e-commerce build. You grant an Editor role on the staging WordPress install, a Read role on the staging GitHub branch, and a viewer seat in analytics. They can see and edit content, but cannot change plugins, deploy, or touch the live database. That is the whole scoping decision in one example.

Now the client's marketing lead asks for "the same access" so she can check copy. You add her to the same client-editors group, which gives her exactly the Editor and Read rights — no re-derivation, no admin creep. Three months later, when the project moves to a maintenance phase, you review the group membership and remove the two people who have left the client's company. The audit log shows the remaining access is still Editor-only. Nothing to clean up, because the design was revocable from the start. We have applied this same pattern across the builds in our portfolio.

Alternatives compared: which access model fits your situation

Choose between full ownership handover, scoped ongoing access, or no direct access with scheduled reports. Full ownership suits a client with an in-house team; scoped access suits an agency that keeps operating the site; reports-only suits a stakeholder who just wants confidence, not buttons. The table below maps the trade-offs.

Model	Best for	Client rights	Operational overhead
Full handover	Client with an internal IT team	Admin on production, repo and hosting	Low for you after handover; high for them
Scoped access	Client who reviews content while you operate the site	Editor/Read roles on staging, viewer elsewhere	Medium — quarterly reviews and a register
Reports-only	Stakeholder who wants oversight, not buttons	None — scheduled exports and walkthroughs	Low — but you carry all changes

The right model is the one whose overhead matches who actually operates the system afterwards. If your team is on call for the site, scoped access is usually the honest middle. If the client is taking the keys entirely, hand over properly and revoke your own lingering tokens at the same time.

In short: grant the least privilege that lets the client do their job, on the environment where mistakes are cheap, through individual accounts you can audit and revoke. Production admin and billing stay yours. The register and the quarterly review are what keep a sensible start from drifting into an over-granted mess six months later.

People also search for

• How to revoke client access when a project ends
• How to audit who has access to a website
• Does hosting choice affect client access control
• What should a web development quote include
• Custom software versus off-the-shelf access requirements
• How to report progress without giving admin access

If you need a second set of eyes on your client access permissions, our team can audit what exists today, write the scoping plan, and set up the roles and the review register. Start with a review, not a pitch — contact us or see how we handle ongoing support across the systems we build and run.