Why tooling matters in co-managed IT
When two teams support the same environment with different tools, things fall through the cracks. A ticket closed in one system is still open in another. A patch deployed by one team breaks something the other team doesn't know about. A password changed at midnight isn't recorded anywhere. Shared tooling fixes that. Everyone works from the same queue, the same device list and the same documentation.
Professional-grade IT management platforms are also expensive to license and run for a team of one or two. Many internal teams make do with a help desk inbox, a spreadsheet of assets and a folder of notes. Through a co-managed agreement, your team gets the same tools our engineers use every day.
What's in the platform
- Remote monitoring and management (RMM): an agent on servers and workstations that reports health, disk space, services and hardware problems, runs scripts and lets technicians connect remotely with user consent where you require it.
- Patch management: operating system and common third-party application updates, with approval rules, pilot groups, maintenance windows and compliance reports.
- Professional services automation (PSA) and ticketing: a shared queue with routing rules, time tracking, a user portal and reporting on volume, response and recurring issues.
- IT documentation: a structured knowledge base for configurations, network diagrams, vendor contacts, procedures and runbooks, linked to the devices and users they describe.
- Credential vault: admin credentials stored in a secured vault with per-person access and an audit trail, instead of a spreadsheet or someone's memory.
- Backup and alert monitoring: backup job results and security alerts surfaced in one place, so failures don't hide in an inbox.
Access your team can trust
An outside provider with admin access is part of your attack surface. Verizon's 2026 Data Breach Investigations Report found a third party involved in 48% of breaches. That's a fair reason to ask hard questions of any IT partner, including us. Here's how we handle access:
- Every technician uses a named account with MFA. No shared logins.
- Access is role-based and scoped to the work in your responsibility matrix.
- Remote sessions and administrative actions are logged, and your team can review the logs.
- Your IT lead can see who on our side has access, and can revoke it.
Who owns what
| Item | Your IT team | Sentry Cloud IT |
|---|---|---|
| Platform licensing and upkeep | I | R, A (included in the agreement) |
| Your tickets, asset records and documentation | A (your data) | R (maintains it) |
| Patch approval rules and windows | A | R |
| Monitoring thresholds and alert routing | A | R |
| User accounts for your staff on the platform | C | R |
| Export of data if the agreement ends | A | R |
What onboarding looks like
Getting the platform in place is usually the first part of any co-managed engagement. We deploy the monitoring agent in stages, starting with a pilot group, so nothing surprises your users. We import existing assets and open tickets, set up routing rules with your IT lead, and move documentation into a structure both teams can find their way around. Patch policies start in report-only mode, so your team can see what would change before anything is installed. Once both teams are comfortable, automation is switched on area by area.
Already have tools you like?
We don't insist on our platform. If your team runs a ticketing system or documentation tool that works, our technicians can work inside it. Some clients use their own ticketing with our RMM and patching. Others move everything to our platform to retire licenses they've outgrown. We'll lay out the trade-offs and let your team decide.
Questions about shared tools & platform
Do we lose access to the tools if we end the agreement?
Access to our platform ends with the agreement, but your data doesn't. We export your tickets, asset records and documentation, and help move them into whatever your team uses next.
Can our team run its own scripts and reports in the RMM?
Yes. Your staff get accounts with the permissions your IT lead approves, including scripting and reporting. We agree on a simple change process so neither team is surprised by the other's automation.
