Most onboarding advice assumes that new hires will not cause trouble in their first week. That is not true for a backend engineer at a payments company.
A new joiner usually needs a laptop, a calendar of introductions and someone to explain the acronyms. A new engineer needs all of that, plus credentials that might allow them to read customer transaction data, deploy to a system that moves money or query a database a regulator considers in scope.[1],[2]
The onboarding template that works for a customer-success hire does not work for an engineer. It usually breaks in one of two ways: the engineer waits, or access arrives before clearance does.
When access arrives too late or too early
If the engineer waits, they spend their week reading documentation. The cost is not only morale. The senior salary paid for documentation reading does not start returning value until access does.
If access arrives before clearance, it is quieter and worse. A manager who needs the work done asks DevOps for credentials. Nobody logs it. Six months later, a compliance lead preparing for an examination discovers that an engineer had read access to production customer data for eleven weeks before their background check was completed.[4],[5]
Nothing bad may have happened. That is not the point. If the business cannot demonstrate that a control operated, it cannot demonstrate the control.[5]
The problem appears more often at companies growing fast. At a software company, engineer onboarding is an engineering topic. At a fintech, the engineer can be the most heavily regulated person you hire, and almost nobody plans for that.
Classify the work, not the title
The obligation is not determined by job title or seniority. It is determined by what the person’s responsibilities require them to do.[2]
A junior developer three weeks into the job may need to debug a failing payment flow, which can mean looking at transactions belonging to real people. Meanwhile, a team lead two levels above them may never need to open production at all.[2]
So the question at hiring is not how senior this person is, or whether they are an engineer. It is what the role’s actual work will require them to see and do, and what that triggers. The classification decision belongs at the point of hire, not at the point of audit.[2]
In most companies of this size, nobody owns that decision. The hiring manager assumes compliance handles it. Compliance assumes the access request will surface it. The access request is a Slack message.
Access is a ladder, not a switch
The real tension is between ramp and compliance. Technical ramp wants access as early as possible, and compliance wants clearance before access. Both are correct. Most companies resolve this badly by picking a side.
The resolution is not a compromise. It is recognising that access is not one thing. Access is a ladder, not a switch.[1]
Almost everything an engineer needs in their first week does not touch production or customer data.[3]
- 01
Provision for a safe first week
Source code and setup, documentation and architecture decision records, a local development environment, staging or a seeded test environment, CI read access, the ticket system, chat, calendar, team rituals, code review and pairing.[3]
- 02
Design a productive first week
When those lists are split, the deadlock dissolves. The first can be provisioned on day one, before or during screening, because it does not create the exposure the control is intended to manage. The second is gated on clearance.[1],[3]
An engineer with the first list can be productive in week one. Not fully, but genuinely. They can read the codebase, fix a documentation gap, write a test and ship something behind a flag against staging.[3]
That is a first contribution. It is what makes someone feel they work here rather than that they are visiting.
What to put in place
The access sequence needs a few deliberate decisions.
- 01
Decide the access tier when the requisition opens
The job description already describes what the person will work on. Record the tier on the requisition and, for the higher tier, the specific systems required.[2]
- 02
Start screening at offer acceptance
If six weeks sit between acceptance and start date, that is six weeks of screening runway. Do not wait for the start date.
- 03
Close the gap between cleared and granted
Check the handoff before assuming screening duration is the problem. Clearance and access are separate events, and each needs an owner.
- 04
- 05
Design the week around the safe tier
Do not make week one a holding pattern. Give the engineer a safe environment and a meaningful first contribution.
- 06
Do not forget offboarding
Giving people access has an opposite half: taking it away. It gets less attention because no one is waiting for it.
An engineer who leaves on Friday and still has access on Monday is a problem. An engineer who moves team and keeps old access is a problem that can remain for years.[4]
If you create an access system, create the removal system at the same time. You will not come back to it later.[4]
What good looks like
An engineer accepts an offer in June. Screening starts that afternoon because acceptance triggered it, not because someone remembered. Their access level is already recorded, so they know what they can and cannot do.[4]
They start work in August. Their laptop is ready, accounts are set up and they have a safe environment plus a meaningful task for the week. Their manager’s first-day meeting was booked in June.
Screening completed in July. The engineer receives the higher tier in their second week and the transition is recorded. Nobody had to wait for anything. Nobody received access they should not have had. When someone asks who had access to what and when, the answer is easy to find.[4],[5]
Waiting costs more than the salary paid while an engineer sits idle. It affects the engineer who was excited to start and instead spends their introduction to the company waiting. It may not make people leave, but it can make them feel differently about the company.
Sources
- National Institute of Standards and Technology. (n.d.). Least privilege. Computer Security Resource Center. https://csrc.nist.gov/glossary/term/least_privilege
- PCI Security Standards Council. (n.d.). Do all PCI DSS requirements apply to every system component? https://www.pcisecuritystandards.org/faqs/do-all-pci-dss-requirements-apply-to-every-system-component/
- OWASP Foundation. (2025). NHI8: Environment isolation. https://owasp.org/www-project-non-human-identities-top-10/2025/8-environment-isolation/
- National Institute of Standards and Technology. (2020). Security and privacy controls for information systems and organizations (SP 800-53 Rev. 5). https://doi.org/10.6028/NIST.SP.800-53r5
- PCI Security Standards Council. (n.d.). PCI Security Standards Council glossary. https://www.pcisecuritystandards.org/glossary/
Where CapoFine fits
Give the access sequence an owner and visible work.
Onboard coordinates stakeholder tasks, meetings, communication, deadlines and progress across preboarding and the first 90 days. The customer’s security, compliance and IT owners remain responsible for clearance decisions and access grants.