The strongest approach is to sequence onboarding around progressive ownership. Start with a buddy, manager context, and team introductions, then move into codebase familiarisation, architecture walkthroughs, small tasks, and review cycles. By day 90, the engineer should be exercising judgment across the stack, understanding deployment and monitoring practices, and connecting technical work to customer and business impact.
Why This Matters for Security Teams
A 90-day onboarding plan is not just an HR exercise; it is a control system for turning a new engineer into a safe, useful operator in a complex platform. Without structure, new hires either get under-scoped tasks that never build judgment or over-scoped access that creates risk. NHIMG’s research shows why this matters: only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges, which means “just let them learn by doing” often becomes an access and accountability problem. The same lesson applies in platform engineering, where early mistakes can cascade across deployment, observability, and incident response. The Ultimate Guide to NHIs — The NHI Market and the TruffleNet BEC Attack — Stolen AWS Credentials both show how quickly weak identity discipline becomes operational exposure when trust is granted too early or too broadly. In practice, many teams discover their onboarding gaps only after a production incident or a stalled ramp has already cost momentum.
How It Works in Practice
The most effective 90-day structure is progressive ownership, with each stage designed to increase scope without skipping context. The first 30 days should focus on orientation: product and platform overviews, team norms, architecture maps, access boundaries, and a clear definition of what “good” looks like. Days 31 to 60 should shift into guided contribution: small production-relevant tasks, pairing on code reviews, fixing low-risk bugs, writing tests, and tracing one service end to end. Days 61 to 90 should test judgment: owning a feature slice, participating in deployment decisions, interpreting monitoring signals, and explaining tradeoffs to adjacent teams.
- Give each new hire one named buddy and one accountable manager.
- Separate learning tasks from production permissions so access expands with demonstrated competence.
- Use a checklist for architecture, tooling, incident workflow, and release process.
- Review progress weekly against concrete outcomes, not just activity.
- Expose the engineer to support tickets, alerts, and customer impact early, so the platform is not abstract.
This approach works best when the platform has stable ownership boundaries and well-documented services. It aligns with broader operational governance principles, including access control, change management, and evidence-based review. For leadership teams also thinking about trust and verification across systems, the FATF’s emphasis on accountable controls in the FATF Recommendations — AML and KYC Framework is a useful reminder that onboarding succeeds when trust is earned through process, not assumed at the start. These controls tend to break down when the platform is heavily tribal, the documentation is stale, and new hires are expected to absorb critical path knowledge only through interrupts and ad hoc pairing.
Common Variations and Edge Cases
Tighter onboarding often increases coordination overhead, requiring leaders to balance speed against safety and team bandwidth. Best practice is evolving for highly complex platforms, especially where teams span infrastructure, data, and application layers, because there is no universal standard for exactly how much responsibility a new hire should own by day 30 or day 60. Senior hires usually need less basic instruction but more context on decision history, architecture tradeoffs, and failure modes. Junior hires often need more explicit task scaffolding and more frequent feedback loops.
A few edge cases change the plan materially. In regulated environments, onboarding may need a longer access review and stronger sign-off before production permissions are granted. In fast-moving startup settings, the risk is usually the opposite: too much access too soon and too little structure. Distributed teams also need more deliberate documentation and asynchronous feedback, or the 90-day target becomes dependent on time zone overlap rather than competence. The practical rule is simple: if the environment is changing faster than the onboarding path, the plan should prioritise learning signals and safe bounded ownership before broad system autonomy.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central to safe onboarding progression. |
| NIST AI RMF | GOVERN | Governance principles help define accountable, repeatable onboarding controls. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity lifecycle discipline parallels controlled access expansion during onboarding. |
| NIST SP 800-63 | IAL2 | Identity assurance helps justify when stronger access should be granted. |
Treat access as a lifecycle: provision narrowly, monitor use, and revoke promptly when no longer needed.
Related resources from NHI Mgmt Group
- Why do static role-based access models struggle as authorization needs become more complex?
- Why does policy as code become risky when authorization logic grows too complex?
- How should a security services company structure a new regional office without adding unnecessary bureaucracy?
- When does secrets discovery become insufficient on its own?
