Onboarding engineers who need production access

A job title is too broad to serve as an access request. Ask the hiring manager to name the initial tasks, then ask the relevant system owners which permissions each task requires. Reading documentation, reviewing source code and deploying a change need separate decisions.

NIST describes least privilege as limiting access to what is necessary for assigned work. Use that principle to discuss the requested permissions with the authorised owner. It does not prescribe a universal engineer onboarding timetable.^[1]

People Operations can coordinate the schedule, but the authorised business and system owners decide whether access is appropriate. Make the handoff explicit: who requests it, who approves it, who provisions it and who confirms that the request was fulfilled.

Ask the responsible People, security and compliance owners whether screening, training or another prerequisite applies to this role and request. The answer depends on the organisation’s requirements. Do not assume that every engineer needs the same check or that completing a check authorises every system.

Record a pending request as pending. If an approval is delayed, agree a different task and a date for reviewing the blocker. Do not share a colleague’s credentials to keep the schedule moving.

A development or staging environment can still contain sensitive data, connected services or powerful credentials. Have its owner inspect the actual configuration and permitted use before including it in the onboarding plan.

Possible first contributions include reviewing approved documentation, pairing on a permitted repository or writing a test using authorised test data. Select work that the engineer is allowed to perform in the environment provided. These are options for the manager to evaluate, rather than a standard set of permissions to grant.

For each request, capture enough context for the approver to make a decision and for the provisioning owner to act. This suggested brief should be adapted to your company’s access-management process.

Consider a fictional crypto exchange hiring a backend engineer. The manager selects a documentation improvement and a test for the first week. The repository and environment owners confirm the permissions and test data that those tasks require.

A later production investigation needs a separate access request. The authorised owner reviews its scope and prerequisites; the provisioning team acts after approval. People Operations tracks the handoff without making the permission decision.

This illustrates role-specific employee preparation at a crypto exchange. It describes a planning approach, not a customer result or a claim about regulatory obligations.

A useful onboarding access plan also names the owner of later reviews. When an engineer changes team or responsibilities, check whether existing permissions are still needed and whether new ones require approval.

Use the company’s agreed leaver process for access removal. Track completion in the authoritative access-management system, including relevant accounts, credentials and system ownership. This article’s planning brief does not replace that process.

Separate request, approval and provisioning dates so you can see where a delay occurred. Review missed prerequisites and reopened requests with their owners rather than treating every delay as a screening problem.

Use the wider employee onboarding checklist for equipment, introductions, learning and manager check-ins. The manager’s onboarding plan can then connect approved technical work to clear early goals.