Before you give an outside developer access to a website, it is worth checking exactly what they need, what they should not see, and how their access will be tracked. In a hosting or managed hosting environment, a small permission mistake can expose customer data, email accounts, DNS records, backups, or even the entire control panel. A clear access review also helps with GDPR-related record keeping and keeps day-to-day operations easier to audit later.
What access the developer actually needs
Start by defining the task in practical terms. A developer fixing a theme issue does not need the same access as someone migrating a site, debugging a plugin conflict, or changing server configuration in Plesk or Apache. The more specific the task, the easier it is to grant only the required permissions.
Separate website access from hosting control access
In many hosting setups, there are several layers of access:
- Website admin access - for example, WordPress, Joomla, Drupal, or another CMS dashboard.
- File access - through SFTP, FTP, SSH, or a file manager in the control panel.
- Database access - such as MySQL or MariaDB credentials.
- Hosting control panel access - for example, Plesk or cPanel.
- Server-level access - SSH with elevated privileges, if absolutely necessary.
If the work can be completed from the CMS, do not grant hosting panel or server access. If file access is enough, avoid sharing database credentials unless the task requires them.
Match access to the exact task
Use the principle of least privilege. Ask yourself:
- Does the developer need to edit content, code, or configuration?
- Will they only review a problem, or will they deploy changes?
- Do they need temporary access to logs or backups?
- Will they work only on one site, one staging environment, or multiple domains?
If the answer is unclear, document the reason before access is granted. This helps later if you need to explain why a specific account was created or why certain logs were checked.
Check ownership, responsibility, and approvals
Before any login details are shared, confirm who has the authority to approve access. This is especially important for agencies, e-commerce sites, membership platforms, and websites with multiple staff members. A developer should never receive access based on an informal message alone if the website belongs to a company with internal approval rules.
Verify who owns the domain, hosting account, and CMS
It is common for different parties to control different parts of a website. For example:
- The domain may be registered with one provider.
- The hosting account may belong to another company.
- The CMS admin account may have been created by an agency years ago.
Check who owns each asset and whether the person requesting access is allowed to grant it. If you use a managed hosting platform, confirm that the account holder or an authorised administrator approves the request.
Record the business reason for access
For compliance and internal control, note why the developer needs access, what system they will use, and for how long. A short record such as “temporary SFTP access for homepage bug fix” is usually enough. This supports privacy and security audits and is useful if you later need to review activity around a site change or incident.
Use a temporary account instead of sharing a main password
One of the most important checks is whether you are about to share a primary login. Do not give out the main admin password for the CMS, hosting panel, or email account. Create a separate account for the developer and restrict it to the minimum required scope.
Create a separate user for each person
Never reuse a shared developer login across multiple people. Individual accounts make it much easier to:
- track who changed what,
- remove access later,
- investigate unexpected changes,
- comply with internal security procedures.
Most control panels and CMS platforms allow multiple users with different roles. Use that capability rather than sending the main password by email or chat.
Set an expiry date
Temporary access should expire automatically whenever possible. If your hosting platform or control panel supports expiry dates, use them. If it does not, set a reminder immediately to review and remove access after the task is complete.
This is especially useful for short troubleshooting jobs, temporary migration work, or emergency fixes outside normal business hours.
Check what data the developer may be able to see
Outside developers often need technical access, but technical access can still expose personal data. On an EU website, this matters because logs, forms, customer records, and backups may contain personal information under GDPR.
Review the sensitive areas first
Before granting access, check whether the developer could see any of the following:
- customer names, email addresses, phone numbers, or order details,
- contact form submissions, support tickets, or CRM exports,
- mailboxes and email forwarding rules,
- payment-related records or invoices,
- backup archives,
- server logs that may contain IP addresses or request details.
If the task does not require access to these areas, exclude them. For example, a front-end designer may only need theme files and staging access, not production databases or mailboxes.
Use staging where possible
A staging environment is often the safest choice for external development work. It reduces the risk of exposing live customer data and makes it easier to test changes before deployment. If your hosting platform supports one-click staging, consider using it for outside developers whenever the project allows.
When using staging, check whether the environment contains copied production data. If it does, apply the same privacy controls as on the live site, including restricted access and logging.
Review the access method before sharing credentials
The way access is delivered matters as much as the access itself. Avoid insecure methods and make sure the developer uses secure authentication wherever possible.
Prefer password managers, SSO, or secure invitations
If your platform supports secure user invitations, single sign-on, or role-based access through the control panel, use those options instead of sending passwords. If you must share credentials, use a reputable password manager with one-time sharing or controlled access, not plain text email.
Enable two-factor authentication
Where supported, require two-factor authentication for any account that can reach the CMS, hosting panel, or SSH. This is especially important for:
- Plesk or other control panel logins,
- admin accounts in WordPress or similar CMS platforms,
- SSH access,
- email accounts used to reset passwords.
Two-factor authentication reduces the chance that a stolen password leads to a site compromise.
Check IP restrictions if they are available
Some hosting environments allow access restrictions by IP address or trusted network. If the developer is working from a stable office or known location, limiting access to approved IPs adds another layer of protection. This is not always practical for remote work, but it is worth considering for sensitive systems.
Decide whether SSH, FTP, or SFTP is appropriate
Not every file-transfer method is equally safe. If a developer needs file-level access, prefer SFTP over plain FTP. If SSH is needed, confirm that the person understands the level of access they are receiving and that their key or password is protected.
Use SFTP instead of FTP
SFTP encrypts the connection, which protects credentials and file contents in transit. Plain FTP should generally be avoided for external access, especially on EU websites handling personal data or administrative files.
Limit SSH where possible
SSH can be useful for debugging, deployment scripts, and command-line tools, but it gives much broader access than a file manager or CMS login. Only enable SSH if the task truly needs it, and use key-based authentication where possible. If your managed hosting environment supports separate SSH users, assign the least powerful one available.
Check database and backup access carefully
Database and backup access often expose the most sensitive information. They should be granted only when there is a clear technical need.
Grant database access only for tasks that require it
A developer may need database access to:
- fix a site migration issue,
- repair broken serialized data,
- adjust plugin settings directly,
- investigate performance or query problems.
If the task is purely visual or involves template changes, database access is usually unnecessary. When access is required, consider using a separate database user with limited privileges rather than the full root or admin account.
Protect backups as sensitive records
Backups can contain everything from content and customer accounts to form submissions and hidden configuration files. Before giving a developer backup access, ask whether they need to restore a file, compare versions, or inspect a copy of the site. If so, limit access to the specific backup set or restoration window.
Also check where backups are stored and whether they are included in the same retention policy as production data. Backups should be part of your record keeping and access review process.
Document the change before and after access is given
A small amount of documentation can prevent confusion later. In a hosting or control panel environment, it is useful to keep a simple record of who was given access, when, and why.
Keep an access log
Record the following details:
- developer name and company,
- date and time access was granted,
- systems accessed, such as CMS, Plesk, SFTP, or database,
- scope of access,
- business reason,
- date access should be removed.
This is helpful for internal governance and may also support GDPR accountability if you need to demonstrate who could access personal data and when.
Note any configuration changes
After the work is complete, document what changed. Include items such as:
- plugin updates or theme edits,
- DNS changes,
- mail routing adjustments,
- cron jobs or deployment scripts,
- server configuration changes in Apache or the control panel.
This creates a clearer support trail and makes future troubleshooting easier.
Check security settings before and after the work
Whenever an outside developer is involved, it is a good moment to review account and site security. A short security check before access is granted can prevent future problems.
Before access is granted
- Confirm the site is fully backed up.
- Review existing admin users and remove obsolete ones.
- Check password strength and two-factor authentication.
- Verify that file permissions are reasonable.
- Make sure the developer’s task is limited to the correct environment.
After the work is finished
- Remove temporary accounts immediately.
- Rotate passwords if a shared credential was exposed.
- Revoke unused API keys, tokens, or SSH keys.
- Check logs for unexpected activity.
- Verify that no test files, debug scripts, or temporary backups were left behind.
If the developer used a control panel such as Plesk, also check whether any new subscriptions, users, scheduled tasks, or file permissions were added during the work.
Common mistakes to avoid
These are the most common problems seen in hosting support cases and security reviews:
- sharing the main admin password with multiple people,
- granting more permissions than the task requires,
- leaving temporary accounts active after the work is done,
- sending credentials over unsecured email or chat,
- forgetting that backups and logs may contain personal data,
- not checking who approved the access request,
- giving SSH access when SFTP or CMS access would be enough.
Avoiding these mistakes lowers both security risk and administrative overhead.
Practical checklist before you share access
Use this quick checklist before handing over any website access to an outside developer:
- Have I confirmed the exact task?
- Is the access limited to the minimum required system?
- Can the work be done in staging instead of production?
- Have I created a separate user account?
- Is two-factor authentication enabled?
- Have I checked whether the developer will see personal data?
- Do I have an access log entry and a removal date?
- Am I using SFTP or secure methods instead of plain FTP or plain text passwords?
- Have I backed up the site before changes begin?
- Do I know how and when access will be revoked?
FAQ
Should I give an outside developer full admin access to WordPress?
Usually no. Give full admin access only if the task truly requires it. In many cases, editor, author, or custom limited roles are enough. If code or plugin changes are needed, consider a temporary admin account with two-factor authentication and a clear removal date.
Is it safe to share Plesk access with a freelancer?
It can be safe if you create a separate user account, restrict permissions, and use strong authentication. Do not share the main account password. Limit access to the relevant subscription or domain if the control panel supports that scope.
Do I need to record temporary access for GDPR purposes?
In practice, yes, it is a good idea. If the developer can access personal data, keeping a basic record of who had access, when, and why supports accountability and helps with internal compliance checks.
What if the developer only needs to fix a front-end issue?
They may only need file access to the theme or template files, or access to a staging site. If no back-end changes are required, do not share database credentials or server-level access.
Should I allow FTP access at all?
If possible, use SFTP instead. Plain FTP is not ideal because it does not encrypt credentials and file transfers. For hosting environments handling personal data, SFTP is the safer default.
How long should temporary access stay active?
Only as long as needed to complete the task. For many jobs, that means a few hours or a few days. If the work is ongoing, review access regularly and remove anything no longer required.
Conclusion
Before giving website access to an outside developer, check the scope of the work, the level of access required, the data that could be exposed, and the way access will be logged and removed. In a hosting or managed hosting environment, the safest approach is to use separate accounts, secure authentication, limited permissions, and temporary access wherever possible. This protects the website, helps maintain good record keeping, and supports practical compliance for European sites.