research
Measuring account provisioning lead time for new starters
A method for measuring how long a new starter waits for working accounts, separating approval delay from build time and vendor dependency.
Use this benchmark to size repeatable IT work, set the review cadence, and decide what stays with the technical owner before assigning the workflow to an IT virtual assistant.
Research playbook
On this pageJump to section
Key stats
Key takeaways
A new starter who cannot sign in on the first morning is a visible failure that often gets blamed on the IT team. The account may have been requested late, held in an approval queue, or delayed by a vendor that never received the right information. This study measures the provisioning lead time from the hiring decision to the first successful sign-in. The result separates the delay the company controls from the delay it does not.
Question and scope
This study asks how long a new starter waits for the accounts and access needed to begin work, and where that time is spent. The unit is one new starter, and the population is every employee or contractor who started during a declared quarter. The result describes that company and period, not the performance of the IT team alone. Freeze the start and finish definitions before collecting data.
Include accounts for email, the directory, the core business application, and the file share. Exclude optional tools that the starter requests after the first week. Record the role and the department because access complexity differs by function. A single average across all roles will hide the cases that fail most often. Separate standard bundles from specialist access in the report.
Define start and finish
Start the clock at the point the hiring manager confirms the start date and the role, not at the offer letter. That confirmation is the earliest moment the company can begin provisioning with confidence. Finish the clock at the first successful sign-in to the core business application, not at the account creation timestamp. An account that exists but cannot be used is not a finished provision.
Record intermediate milestones such as the request submitted, the approval granted, the account created, and the first sign-in. The milestones are what make the delay visible by stage. Use one timezone and one business calendar so the stages can be compared. Document any stage the system does not capture. If a milestone is missing, say so rather than estimating it silently.
Build the request frame
Export the starter identifier, the role, the department, the start date, and each milestone timestamp. Link the request to the ticket or workflow that handled it. Add the systems requested and the systems actually used on the first day. Reconcile the count with the human resources starter list and explain any difference.
Normalise the roles into a small set based on the access bundle rather than the job title. Two different titles may need the same bundle, while one title may have several variants. Record the bundle used for each starter. The bundle is the unit that can be improved, because it defines the work required. Review the bundle with the hiring manager before the next quarter starts.
Separate vendor and internal steps
Identify the steps performed by a vendor, such as a payroll platform or a managed service provider. Record the handoff time and the vendor's response time separately from the internal work. A vendor delay is still the company's problem for the starter, but it needs a different remedy. Combining the stages hides which relationship needs attention.
Check whether the vendor receives complete information at the first request. A missing cost centre or manager name can send the request back and restart the clock. Record the number of requests returned for more information. That count is a practical measure of the handoff quality. A returned request should restart the clock at the moment the missing information arrives.
Measure the working-day lead time
Report the median and the ninetieth percentile in working days, and show the stage where the most time is spent. Add the count of starters in the sample so a single case is not overread. A median of two days can still hide a tail of starters who waited a week. Report the number of starters who were not ready by the first morning. That number matters more to the hiring manager than the average. Show it by department so the owner can see where the failures concentrate.
Compare the lead time with the company's stated commitment to new starters. If no commitment exists, propose one based on the measured distribution rather than an aspiration. Record the date and the owner of the commitment. A target without an owner will not change the process. Publish the target where hiring managers can see it before they set a start date.
Sample the late cases
Read the full history for every starter who was not ready on the first morning. A starter who was ready but waited for a single tool should be recorded separately. Look for the stage where the request stopped and the reason it stopped. Classify the cause as late request, missing information, approval delay, build delay, or vendor delay. Use one category per case and note any contributing factor. The contributing factor is often the more actionable of the two.
Ask the hiring manager what they expected and when they submitted the request. Their expectation is part of the problem, because a manager who assumes IT knows about a new hire will always be disappointed. Record the communication that set the expectation. The fix may be a simple change to the offer or onboarding checklist. Test the wording with one hiring manager before rolling it out.
Find the approval bottleneck
Count the approvals required for a typical starter and the time each one takes. Compare the count with the risk of the bundle rather than with the seniority of the approvers. A bundle that needs five approvals for standard access is a design problem, not a diligence problem. Identify the approvals that add real risk control and the ones that merely repeat a previous decision. Record the evidence for each recommendation. A short table of approval, owner, purpose, and average wait is enough.
Check whether approvals can be granted in parallel rather than in sequence. A sequential chain multiplies the delay whenever one approver is away. Test a parallel path for a low-risk bundle and measure the result. The change should reduce waiting without removing the control. Record which approvals were merged and who accepted the risk.
Report to the hiring owner
Present the lead time, the stage breakdown, and the number of starters who were not ready on day one. Put the definition of ready at the top of the report so the numbers are unambiguous. Show the causes in order of frequency and the roles most affected. Add one example of a late case with the identifying details removed. The hiring owner should be able to see where their own request timing contributes. Avoid ranking managers by late requests, because the process may be the real cause.
Ask for two decisions: approve a standard access bundle and agree on a request deadline before the start date. Name the owner and the review date. If the decision is to keep the current process, record the accepted risk. A clear decision is better than another round of blame. Share the stage breakdown with the hiring managers so they can see their part of the delay.
Limits and next use
The study measures starters who appear on the human resources list and milestones the systems recorded. It does not capture access granted informally before the first day or work performed on a personal device. It also cannot prove that a faster provision produced a better first week. State those limits so the lead time is read as one part of the onboarding experience.
Repeat the measurement after the bundle and deadline changes, using the same stages. If the lead time falls but the number of access corrections rises, the faster bundle may be too broad or too narrow. The next study should add the starter's own report of what was missing on the first day. A short survey is enough when it asks about specific systems.
Recheck after a change
Run the same measurement for one quarter after the change and compare the stage breakdown. Look for improvement in the stage you changed and for new delays elsewhere. A faster approval step can expose a build bottleneck that was previously hidden. Report both the intended and the unintended effects.
Keep the method and the raw export with the onboarding checklist. When the next manager takes over, the comparison should be possible without rebuilding the study. Schedule the review at the same time as the quarterly access review. Provisioning quality and access accuracy are closely related. A starter who receives too much access creates a cleanup task later.
Sources and next step
Use the NIST Cybersecurity Framework 2.0 and the CISA Cross-Sector Cybersecurity Performance Goals as primary references for the identity, asset, and vendor controls discussed here. The GAO data reliability guidance supports the sampling and verification approach used in these methods. Apply your own policies, contracts, and system documentation when adapting the method.
Compare this study with the asset record accuracy study and the account provisioning lead time study before combining them into one review cycle. If the measurement work is recurring and your technical owner can define the scope, review the service areas and contact ITVirtualAssistant to discuss a limited pilot.
Benchmark brief
What this research page must produce
A practical estimate for volume, review time, escalation rate, and assistant capacity.
A clear split between routine support, preparation work, and technical ownership.
What the measuring account provisioning lead time for new starters data shows
Treat this as a planning benchmark, not a universal number. Compare the benchmark against your ticket volume, SaaS stack, documentation backlog, and support risk before assigning recurring work.
The useful output is a decision about capacity, not a static statistic. If the workflow is high volume and low judgment, an IT virtual assistant can absorb coordination and upkeep. If the workflow is low volume but high risk, keep it with the technical owner and use the assistant only for preparation, reminders, and documentation.
Workflow
Recommended operating workflow
Collect a baseline
Pull the last 30 to 90 days of examples related to measuring account provisioning lead time for new starters, including completed work and unresolved exceptions.
Classify the work
Tag each item by routine admin, manager approval, technical decision, security risk, or vendor dependency.
Set the operating number
Use the median weekly volume and review time to decide how many assistant hours the workflow deserves.
Refresh the benchmark
Recheck the numbers quarterly so tool growth, new systems, and security requirements do not silently change the scope.
Decision rules
| Metric | Use it to decide | Manager action |
|---|---|---|
| Weekly volume | Whether the workflow is worth assigning as recurring assistant work. | Approve a weekly capacity target and backlog threshold. |
| Access sensitivity | Whether the assistant can work directly or only prepare review notes. | Set least-privilege permissions and removal dates. |
| Escalation rate | Whether the workflow is stable enough to delegate. | Rewrite the SOP when exceptions exceed the agreed threshold. |
Consolidated statistics
| Statistic | Figure | Source |
|---|---|---|
| Review window | 1 quarter | Study protocol |
| Milestones | 4 | Study protocol |
| Cause groups | 5 | Study protocol |
Sources
- NIST SP 800-53 Rev. 5Account management and least-privilege controls for provisioning.
- CISA Cross-Sector Cybersecurity Performance GoalsPractical identity lifecycle goals for small organizations.
- NIST Cybersecurity Framework 2.0Identity management and governance outcomes.
- GAO Assessing Data ReliabilityMilestone and completeness checks for workflow evidence.
- Computer Support SpecialistsOccupational context for account administration work.
Measurement checklist
| Field | What to capture | Owner |
|---|---|---|
| Volume | Weekly request count, backlog age, and repeat issue patterns | Assistant prepares, manager reviews |
| Risk | Access level, customer impact, security sensitivity, and approval needs | Technical owner |
| Cadence | Daily, weekly, monthly, or quarterly review rhythm | Manager |
| Evidence | Sample tickets, logs, screenshots, and before-after examples | Assistant collects, owner validates |
| Escalation | Triggers, approval path, response time, and stop-work rules | Technical owner |
How to read the result
A good research page should leave the manager with a working number and a clear boundary: what the assistant can do every week, what the assistant can prepare for review, and what must never move without the accountable technical owner.
Source and refresh note
This planning page is dated for 2026 and should be refreshed quarterly as tool stacks, ticket patterns, and security expectations change.
How should teams use this benchmark?
Use it to define task volume, access limits, review cadence, and escalation rules before assigning work.
Get free benchmark review