Our 30-day IT onboarding process, day by day
Every IT provider says their onboarding is thorough. This page shows what ours actually contains: what happens in which week, what we'll ask you for, what gets locked down, and what you're holding at day 30. Each step produces something you can see, so if a step doesn't happen, you'll know.
/ At a glance
Duration
30 days from signed agreement to the first monthly report
What we need from you
A named contact, approval for access, and a few short working sessions
What you keep
Inventory, risk register, security baseline, runbooks, escalation matrix and roadmap
/ Direct answer
What happens in the first 30 days of IT onboarding with BPro Technologies?
The first 30 days run in four stages. Days 1 to 5 cover access and discovery. Days 6 to 12 deploy monitoring, endpoint protection, backup visibility and ticket intake. Days 13 to 20 set the security baseline and lock down the gaps found. Days 21 to 30 finish the runbooks, escalation matrix, first report and a 90-day improvement roadmap.
- Urgent risks fixed in week one
- Nothing disruptive without a pilot
- All documentation stays with you
/ 01
What happens in days 1 to 5?
Access and discovery. We collect admin access through a secure handover (never by email), list every vendor and contract, inventory users, devices, licences, cloud tenants and network equipment, and flag anything urgent, such as an admin account without MFA or a backup that hasn't run for weeks. Urgent risks get fixed now, not at day 30.
| Day | Activity | What you'll see |
|---|---|---|
| 1 | Kickoff call; contacts and approvers agreed | Kickoff notes and an access plan |
| 2–3 | Admin access handover, including from any previous provider | Access register: who has what |
| 3–5 | Users, devices, licences, tenants, vendors and network inventory | Draft inventory |
| 5 | Urgent risk triage | Urgent risk list, with the actions already taken |
/ 02
What happens in days 6 to 12?
The tooling goes in. Monitoring agents are deployed to devices and servers, endpoint detection and response is rolled out (or your existing tool is brought under management), backup jobs are connected to reporting, and your staff get the support channel they'll use from now on. None of this should disrupt anyone. It runs in the background.
Monitoring and RMM agents
Deployed through existing management tools, so remote laptops are covered too.
Endpoint detection and response
Rolled out in detect-only mode first, then switched to blocking.
Backup visibility
Every backup job reports into one place, including Microsoft 365 data.
Ticket intake live
Staff get the email address, portal or phone line for support.
We report deployment coverage as a number during this stage (devices with agents against devices in the inventory), so gaps are visible straight away.
/ 03
What does the security lockdown in days 13 to 20 include?
The security baseline: MFA enforced for everyone, admin roles reduced and separated from day-to-day accounts, legacy authentication blocked, endpoint protection confirmed on every device, patch policy applied, email authentication (SPF, DKIM, DMARC) checked, and backup gaps closed. Anything that affects how people sign in is piloted and announced first.
| Control | What we check | Common first-review finding |
|---|---|---|
| MFA | Registration and enforcement for every account | A handful of accounts never registered |
| Admin accounts | How many, and whether they're separate from daily use | More Global Administrators than anyone realised |
| Legacy sign-ins | Sign-in logs for old protocols | Old devices or scripts still using them |
| Backups | Job success and what's actually covered | Microsoft 365 data not backed up at all |
| Email authentication | SPF, DKIM and DMARC records | DMARC missing, or left at p=none |
| Endpoints | Protection, encryption and patch level | Laptops without disk encryption |
/ 04
What do you hand over at day 30?
A documented operating model: the full inventory, access register, risk register with owners and dates, security baseline results, support runbooks, escalation matrix, the first monthly report and a 90-day improvement roadmap. You keep all of it. If you ever change provider, the next one starts from documentation instead of guesswork.
- Device, user and licence inventory
- Access register
- Risk register with owners and dates
- Security baseline results
- Support runbooks and escalation matrix
- First monthly report and 90-day roadmap
/ 05
How can we make onboarding go faster?
Three things help more than anything else. Confirm who on your side can approve access and changes. Get the outgoing provider to hand over admin access and documentation promptly. And tell us early about the systems that only one person knows about. Onboarding slows down on missing access, not on technical work.
Frequently Asked Questions
Most of it runs in the background. The exceptions are MFA enforcement, device compliance and anything else that changes how people sign in. Those are piloted, scheduled and announced beforehand.
It helps a lot, but we can onboard without it. If a handover is slow or incomplete, we recover access through Microsoft or the relevant vendor's admin recovery process with your authorisation, and document anything that couldn't be found.
Ticket intake starts during days 6 to 12, once we have enough context to handle requests properly. Anything urgent found during discovery is dealt with straight away.
For small, well-documented environments, yes. For larger ones or messy handovers, some stages run longer. The order never changes: we don't enforce security changes before we understand the environment.
The fixes that were too big for onboarding: device replacements, licence changes, migrations, policy projects and anything needing budget. Each item has a reason, an owner and a suggested order.
/ Next step
Want this reviewed against your own environment?
Share your users, tools and the problem you are trying to solve. We will tell you plainly whether this service fits, and what we would look at first.