Short answer: security and IP with a nearshore team are not about trust; they are about structure. Named accounts instead of shared logins, least-privilege access through your own identity provider, documented device and secret handling, contractual IP assignment, and an offboarding checklist with timings. Get those five right and the rest is ordinary engineering hygiene. Skip them and you have outsourced your access control to a spreadsheet nobody reviews.
Access is a lifecycle: grant by role, review on a schedule, revoke on the day someone leaves.
Decide what you require before you sign
Most security problems with external teams trace back to decisions that were never made explicitly. Before signing, be able to answer these:
- Whose identity provider authenticates the team — yours, or theirs?
- Which systems does the team reach, with what role, and who approves new access?
- Where does source code live, and who owns the repository organisation?
- How are production secrets distributed and rotated?
- What happens on a laptop, and what happens if one is lost?
- Who can access production data, and is that access logged?
- What is the process on the last day of an engagement?
If the answer to any of these is "we will figure it out", you have found the first item on your risk register.
Access: named accounts, least privilege, SSO
The baseline is not complicated, but it has to be enforced rather than encouraged.
- One named account per person. Shared logins destroy accountability and make revocation guesswork. If a tool requires a shared credential, it should be a break-glass credential stored in a vault with logged access.
- Your identity provider, not theirs. Team members authenticate through your SSO, with MFA enforced. This makes joining and leaving a single action, and it gives you the access log you will need for reviews.
- Roles, not individuals. Grant access to groups that map to responsibilities: developer, reviewer, deployer, on-call. Personal grants accumulate and are never cleaned up.
- Least privilege for production. Most of the team needs staging and read-only production observability. Write access to production data should be a small, named group with an approval path.
- No standing production database credentials. Prefer short-lived credentials issued by your cloud provider or a bastion, not a password in a shared environment file.
- Review quarterly. Export the access list, compare it with the team roster, and remove anything that does not map to a current responsibility. Record the review.
| Access tier | Typical holder | Scope | Review cadence |
|---|---|---|---|
| Read-only observability | Whole squad | Logs, metrics, error tracking | Quarterly |
| Development | Engineers | Repositories, CI, staging | Quarterly |
| Deployment | Tech lead, on-call | Deploy pipeline, environment config | Quarterly |
| Production data | Two named engineers | Scoped, audited, time-bound | Monthly |
| Billing and vendor accounts | Delivery lead | Cost and contract management | Quarterly |
Devices, secrets, and local development
The team's laptops are part of your attack surface, so say so in the working agreement.
- Full-disk encryption, screen lock, and automatic updates are minimum expectations, not preferences.
- A password manager is mandatory; credentials do not live in chat, tickets, or notes.
- Secrets are stored in a managed secret store with access logging, not in
.envfiles passed around. - Production data does not get copied to laptops. If a task needs production data, use a masked or sampled copy in a controlled environment.
- Code review requires a second person, and the person who approves a change should not be the only person who can deploy it.
- Personal projects do not share credentials with client work, and client code does not sit on unmanaged machines.
IP assignment and code ownership
IP hygiene is a contract and repository question, not a cultural one.
- The contract assigns IP on creation. A clause that assigns deliverables on payment is weaker than one that assigns work product as it is created, with a further assurance clause requiring signature of anything needed to perfect the assignment.
- The client owns the repository organisation. Vendors get membership, not ownership. This is the single most important structural decision, because it makes every other handover question trivial.
- Third-party and open-source obligations are tracked. Maintain a dependency and license inventory, and require disclosure before a new copyleft dependency enters a product that ships to customers.
- Contributor identity is real. Each commit maps to a person, and contractors have signed whatever their jurisdiction requires for work-for-hire to be effective.
- AI-generated code has a policy. Decide whether assistants are allowed, which ones, what data may be sent, and who reviews the output. "Everyone uses whatever they like" is a policy, and a risky one.
Offboarding that actually revokes
The last day is where most organizations lose control, because revocation is spread across a dozen systems.
- One checklist, one owner, timings. Identity provider first (which cascades to most tools), then cloud, repository, secret stores, third-party services, and communication channels.
- Revoke, then rotate. Removing a user does not invalidate a token they copied. Rotate any credential they could read.
- Handle the laptop. Either the device is returned and wiped, or it is verified as encrypted and remote-wiped with a signed attestation.
- Transfer knowledge before access ends. A short handover document and a recorded walkthrough of anything only that person knew.
- Record the completion. An offboarding record with timestamps is the artifact that answers the question "was this person's access removed" a year later.
Questions to ask a prospective partner
| Question | A strong answer looks like | A weak answer sounds like |
|---|---|---|
| How do your engineers authenticate? | Through client SSO with MFA, named accounts | "We have our own logins we share with the client" |
| Where do production credentials live? | Managed secret store, short-lived, audited | "In the environment file on the server" |
| Who owns the repositories? | The client's organisation, vendor as member | "We host it on our GitHub" |
| How do you handle a lost laptop? | Remote wipe, rotation plan, documented drill | "It has not happened yet" |
| What does offboarding include? | Checklist with timings and an evidence record | "We remove them from Slack" |
| How do you handle AI coding assistants? | Written policy, approved tools, review rules | "Whatever speeds people up" |
These questions also show up in commercial evaluation, where weak answers tend to cluster: our outsourcing red flags covers what to watch for before a project starts.
Limitations and assumptions
This baseline assumes the client has an identity provider and cloud account of their own; a startup running everything on personal accounts should fix that first, because no vendor arrangement can compensate for missing ownership. It assumes the engagement has a contract with an IP assignment clause reviewed by counsel in the relevant jurisdictions, which varies by country and cannot be replaced by a paragraph in a statement of work. It assumes a team size where quarterly access reviews are tractable; at larger scale the same controls need automation. Finally, security controls are not free — a stricter posture adds friction to onboarding and to production access — so the design goal is proportionate control over the systems that matter, not maximum restriction everywhere.
Working with CodeAustral
We work inside client identity, repositories, and cloud accounts by default, with named accounts, SSO, scoped production access, and a documented offboarding process. If you are setting up a nearshore engagement and want the security and IP structure agreed before the first sprint, read how we run nearshore delivery or send a brief and we will walk through the checklist with you.
Frequently asked questions
Do we need to run background checks on a nearshore team?
That depends on your industry and your contracts. What matters more is structural: named accounts, least privilege, and logged access to sensitive systems. Background checks are a control on individuals; access design is a control on the system, and it works regardless of who joins.
Is it acceptable for the vendor to own the repository?
It is acceptable only if you have a tested exit path. Owning the repository organisation removes an entire class of handover risk at almost no cost, so most companies should simply require it. If a vendor insists on hosting, require a mirror in your organisation with full history, updated continuously.
How do we handle production access for on-call engineers?
Give on-call access to observability and deployment, and keep direct production data access separate, scoped, time-bound, and audited. Most incidents are resolved with logs, metrics, and a deploy, not with a database session.
What is the biggest security mistake companies make with nearshore teams?
Treating the engagement as an exception to their own rules. The same controls that apply to in-house engineers — SSO, least privilege, secret management, offboarding — should apply to the external team, with the same reviews and the same evidence. Exceptions are where incidents live.