The security question about a nearshore engineer usually arrives phrased as a country question — is it safe to have someone in Brazil touching our systems? That framing hides the actual risk, which has never been where the person sits. It is what the account can reach, whether anyone would notice, and how fast it stops when the engagement ends.
A contractor abroad with scoped, logged, individually named access is lower risk than a full-time employee with a shared admin credential and no audit trail. Here is the model that holds up, including under a SOC 2 question.
Named accounts, least privilege, no exceptions
Every access the engineer has is issued to them personally and scoped to what the work needs this month. That means no shared logins, no team password for the cloud console, no "temporary" admin that quietly becomes permanent.
The practical test is a question you should be able to answer in under a minute: if this person's credentials leaked tonight, what exactly could be reached? If the answer is a list you can state, the model is fine. If the answer is "everything, they are on the team account," the problem was there before the contractor was.
Route everything through SSO with enforced multi-factor, and review the grants when the scope of work changes rather than never. Quarterly access reviews are the standard cadence; for a small team, reviewing when someone's project changes is more honest than a calendar ritual nobody reads.
Production data is the actual crown jewel
Most real incidents involving contractors are not exfiltration — they are a copy of the production database sitting in a development environment because that was the easiest way to reproduce a bug.
Two rules cover most of it:
- Development and staging get anonymised or synthetic data. If reproducing a bug genuinely requires real records, it requires a documented, time-boxed, logged access to a restricted environment — not a dump.
- Production access is separate, explicit and rare. Read-only where possible, broken-glass with an alert where not, and always attributable to a named person.
This applies identically to an employee in your office. The contractor conversation simply makes teams notice it, which is the one genuine benefit of the question.
The device question, answered honestly
An engineer contracted through a studio works on their own machine. That is the normal arrangement and pretending otherwise helps nobody. What you can reasonably require, and verify:
- Full-disk encryption on, screen lock under five minutes.
- Operating system and browser current.
- A password manager, with the work credentials living in it and nowhere else.
- Source code stays in the repository, not in personal cloud folders or unmanaged copies.
If your compliance posture genuinely requires a managed device, say so in the brief, before the engagement. It is a normal requirement and it can be met — by shipping a managed laptop, or by moving the work into a virtual desktop so nothing lands locally. What does not work is requiring it in month three, after the work has been happening on an unmanaged machine, and treating it as a surprise.
Contracts carry the parts that tooling cannot
Access control handles what a person can do. Three clauses handle what they may do, and they need to be in the agreement with whoever holds the Brazilian relationship:
- Confidentiality that survives termination, with a stated period.
- IP assignment naming the deliverables and not limited to the term. Brazilian law does not assign work product by default the way a U.S. employment relationship does — the IP and NDA guide covers what actually holds.
- A breach-notification obligation with a time limit, so a lost laptop reaches you in hours rather than whenever it comes up.
Where the engineer is contracted by a studio rather than by you, these clauses live in your agreement with the studio and are passed down — which is also the answer to "who is accountable" when an auditor asks. The piece on PJ contractors explains who holds what in each structure.
What an auditor will actually ask
If you are in a SOC 2 or ISO process, the contractor questions are narrower and more boring than teams expect. Be ready with:
- A list of every third party with system access, and what each one can reach.
- Evidence that access was granted through an approval, not an ad-hoc invite.
- Evidence of periodic access review.
- A signed confidentiality and IP agreement per person or per vendor.
- Offboarding records showing access removal, with dates.
Every one of those is a process artifact, not a nationality question. Auditors do not object to contractors abroad; they object to access nobody can account for.
Three controls that are not worth what they cost
Being honest about the ones that look reassuring and buy little:
- Blanket IP allowlisting. A residential connection in Brazil changes address regularly, so the rule becomes a support ticket every few weeks and gets disabled within a month. Device posture and multi-factor are what you actually wanted.
- Screen monitoring and activity tracking. It generates data nobody reviews, damages the relationship with a senior engineer, and catches none of the failure modes that matter. Output review is both cheaper and more informative.
- Blocking copy-paste or downloads at the browser. Trivially bypassed by anyone with terminal access to the repository — which your engineer necessarily has. It signals distrust without changing what is possible.
Spend the same effort on access scoping, production data hygiene and the offboarding checklist and you get a control set that survives an audit instead of one that survives a slide.
Offboarding is the control that fails most often
Write the checklist once and run it on the last day, identically every time: source control, cloud console, CI, databases, observability, password manager, SSO, shared drives, project tracker, personal API keys, VPN. Rotate any shared secret the person could have seen. Record the date.
The failure mode is not malice. It is an account that stays live for eight months because nobody owned the removal — and it is the single finding most likely to appear in your first audit. The fix costs fifteen minutes on a day you already know is coming.
The short version
Scope the access, keep production data out of development, require a device baseline you can verify, get the three clauses in writing, and offboard on the last day. Do that and the fact that the engineer is in Curitiba rather than Chicago stops being a security variable at all — which is the correct outcome, because it never really was one.