When you add a remote engineer, you’re giving someone outside your office access to your clients’ systems. That’s true of any new hire, but distance makes MSP owners rightly ask harder questions. Who controls the device? What happens to access when someone leaves? Could a client contract or regulation say no?
The good news is that every one of these risks has a practical answer, and most of them are the same controls you should already have for local staff.
What are the biggest security and compliance risks with remote MSP staff?
The main risks are too much access, devices you don’t control, weak offboarding, client or regulatory restrictions on who can access data, and engineers whose employment status leaves gaps in accountability. Each can be resolved with access control, managed devices, clear contracts, and checking client requirements before assigning work.
The risks and how to resolve them
| Risk | What can go wrong | How to resolve it |
|---|---|---|
| Too much access | A new tech gets admin rights to every client on day one | Grant least-privilege access by role, and expand it as trust and need grow |
| Unmanaged devices | Client data on a personal laptop you can’t see or wipe | Require a dedicated laptop managed with your tools and security standards |
| Weak offboarding | Access lingers after someone leaves | Use named accounts, MFA, and a written offboarding checklist you can run in minutes |
| Client and regulatory restrictions | A client contract or regulation limits who can access its data, or from where | Check contracts before assigning work; keep restricted accounts with staff who meet the requirement |
| Unclear employment status | A contractor with no employer, no notice period, and no formal accountability | Work with engineers who are legally employed, with formal contracts and HR behind them |
| Unknown history | Nobody checked who you’re trusting with client systems | Require background and reference checks before you interview |
A checklist before day one
- Confirm which clients your new engineer will support, and check those clients’ contracts for restrictions on offshore access.
- Set up a named account with MFA in every tool, never a shared login.
- Issue a dedicated laptop enrolled in your device management, with your security baseline applied.
- Grant least-privilege access by role, documented in one place.
- Walk through your security policies and how to report an incident.
- Write the offboarding steps now, while it’s easy.
This is general guidance, not legal advice. If you support clients in regulated industries, confirm their specific requirements before giving any new engineer access.
Why employment status is a security question
It’s easy to treat employment as an HR detail, but it affects your risk. A legally employed engineer has a formal contract, an employer responsible for conduct and compliance, and a notice period, so nobody walks away overnight with access still live. A loosely engaged contractor may have none of that. Here’s a full comparison of the three models.
How Scaled approaches security and compliance
Every engineer we place is a full-time, permanent employee of Scaled Workforce (Pty) Ltd, our South African company, with an employment contract under South African labor law. We handle payroll, tax, and statutory contributions, and every candidate has passed a background check and reference checks before you meet them.
On your side, you stay in control: your engineer works on a laptop dedicated to your MSP and managed by you, with the access you choose to grant. Scaled Inc. is a US company, and we invoice in US dollars.
Frequently asked questions
Can a remote engineer meet my clients’ security requirements? Usually, yes, when they work on a managed device with named accounts, MFA, and least-privilege access. Check each client’s contract for any restrictions on offshore access first.
Who’s responsible if something goes wrong? With a legally employed engineer, there’s a formal employer handling HR and conduct, and you control the access. Agree on how incidents are reported before day one.
Should a remote tech use their own computer? No. Use a dedicated laptop that you manage, so you control security settings and can remove access instantly.
Do you run background checks? Yes. Every candidate completes a background check and reference checks before they’re presented to you.