On day one, a contractor should have a signed agreement, a personal GitHub account with two-factor authentication, access to one repository at the lowest useful role, and a recorded end date. Everything else, such as more repositories or higher roles, is added later on request.
Before they get access
Do these in order. If one step is not ready, the access waits.
- Agreement signed. The statement of work covers confidentiality, where code may be stored, and what happens at exit. Have your legal advisers draft it.
- Sponsor named. One staff member is responsible for the contractor and approves access requests.
- Identity confirmed. You know who the person is and which GitHub account is theirs. Ask them to use a personal account tied to them, not a shared one.
- Two-factor on. If your organization requires 2FA, GitHub states that outside collaborators must enable it before accepting your invitation. Confirm they have, and see what happens when you require 2FA.
The access grant
| Item | Day one setting |
|---|---|
| Account type | Outside collaborator unless there is a reason, see member or collaborator |
| Repositories | The one they need first |
| Role | Write for developers, lower for others, see role guide |
| Tokens | None until requested through your policy |
| Secrets | None in the repository, test credentials only |
| End date | Recorded in the access register |
What the repository should already have
A new contractor should arrive at a repository that protects itself. Check these before you invite anyone:
- Required pull request reviews on the default branch, so, as GitHub documents, changes reach a protected branch only through an approved pull request.
- Code owner review for sensitive paths, with owners who have write permission.
- Dismissal of stale approvals when new commits arrive.
- Secrets for deployment held in protected environments, see protecting deployment secrets.
- A README with the build steps so they do not ask for credentials to get started.
The welcome note
Send a short message with the rules, so nobody learns them by breaking them.
- Work in branches or forks and open pull requests, never push to the default branch.
- Do not paste credentials into tickets or chat.
- Do not add third party packages without approval, see dependency approvals.
- Use only the AI coding tools named in your policy, see the AI coding policy for contractors.
- Store code only on devices and locations the agreement allows.
- Report anything odd, including a lost laptop, the same day.
Data and environments
Contractors should work against fake or masked data. The post on what to give a contractor instead of a production dump covers how.
Record it
Add the contractor to your register with the sponsor, repository, role, approval date and end date. Set a reminder a week before the end. Without this row, you cannot run the monthly review or the offboarding checklist.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at which checks run before a pull request can merge, since those are what protect a repository on a new contractor's first day.
Safeguard's policies and gates can enforce those pull request checks from the first commit, and its asset discovery helps keep your register of repositories complete. Start with the free scan.
Quick check
Should a new contractor get access to every repository?
No. Start with the single repository they need and add others on request, each with its own approval and end date.
Do outside collaborators need 2FA before accepting an invitation?
If your organization requires two-factor authentication, GitHub says they must enable it before accepting.
Sources
Last reviewed: 19 October 2026.
