What a Co-Managed IT Relationship Actually Looks Like Day to Day

Day to day, co-managed IT means your internal person keeps the users, the vendors, and the office context, while an outside team takes monitoring, patching, security tooling, and overflow tickets, under a split that was written down first.

Most writing about co-managed IT stops at the concept. Two teams, one environment, everybody wins. Fine as far as it goes. Which is not far.

What owners actually ask me is smaller and more boring than that. Who picks up the phone on a Tuesday morning. Which person holds the firewall password. What happens the week somebody quits. Whether their IT guy is now going to spend his day writing tickets for somebody else instead of doing his job.

So this is the operational version. Not what co-managed IT is, since the decision side of that question got its own piece, but what a normal week looks like once the paperwork is done.

VJNetworks runs co-managed IT engagements alongside fully managed ones for businesses with roughly 5 to 60 employees in Rockland, Westchester, and Bergen. What follows is how ours are structured. Ask whoever else you are talking to for their version of the same document, and compare the two.

Where a Ticket Goes First

One operational decision matters more than the rest of them put together, and almost nobody makes it deliberately. One queue, or two.

Companies drift into two doors, because drifting requires no meeting. Staff email the internal guy for the small stuff and open a ticket with the provider for the big stuff. That holds up beautifully until the morning nobody can agree on what counts as small, and a mailbox permission request sits in somebody’s inbox for two days because each side assumed the other had it.

Everything lands in one system instead. Both teams see every ticket from the moment it opens, including the ones they will never touch. Routing happens by category, written down in advance, not by whoever guesses the ticket is hard. Written down. In advance.

That last row is the one that keeps the arrangement honest. Uncategorized tickets are not failures. They are the only reliable signal that the document is out of date.

Escalation runs a fixed path and it is short. The category owner takes it, and if it stops moving, it goes to the senior engineer on that system, and then to the named lead on the engagement. Three stops. Every one of them is a person your team can name before they need to. If a provider cannot tell you today who the third stop is, they do not have a third stop.

On the clock, be careful what you accept. Our 15-minute response standard is a business-hours commitment, and I would rather say that here than let you find it in month three. It also means response, a person picking the thing up, not repair. Whatever coverage exists outside business hours belongs in the scope document in writing, in the words your provider actually means, because “we’ve got you covered” is not a coverage window. The same discipline applies to how the help desk itself is staffed. Ask the boring question. Get the boring answer in writing. Then hold them to it.

Who Owns Which System

NIST rewrote its Cybersecurity Framework in February 2024 and added a whole GOVERN function, and buried in it is a line that reads like somebody wrote it after watching a co-managed engagement go sideways. Cybersecurity roles and responsibilities for suppliers, customers, and partners are established, communicated, and coordinated internally and externally. That is subcategory GV.SC-02 of the NIST Cybersecurity Framework 2.0, and one of its own implementation examples tells you to create responsibility matrixes recording who is responsible and accountable, and how the other parties get consulted and informed.

Which is a formal way of saying build the table. So here is ours.

Underneath every row is the same division, and it is worth stating out loud because both sides have to actually believe it for the arrangement to work. Your person is the expert on your staff, your company, and everything internal. We are the experts on the technical side. Neither of those is the senior one. Engagements that go wrong are almost always ones where somebody quietly decided otherwise.

Copy that table, argue with it, change half of it. Good. That is the point. A company whose IT lead is genuinely strong on networking keeps the firewall row and hands VJNetworks more of the Microsoft 365 row instead. The specific allocation matters much less than the fact that two teams sat down together, went row by row through everything the business actually runs, and put a single name in every box before anything went wrong rather than after.

CISA files this under change management. Goal 3.N in its Cybersecurity Performance Goals asks for processes that prohibit unauthorized changes unless approved. In a one-team shop, unauthorized is an easy word, because there is only one team and everybody knows who they are. Put two teams in the same tenant and the word means nothing at all until a matrix like the one above exists to define it.

Access, Admin Rights, and the Two Accounts Nobody Ever Uses

The lazy version of shared access is that both sides get Global Administrator in Microsoft 365 and everybody promises to be careful. It is common. It is also the exact arrangement Microsoft spends an entire best-practices page telling you not to build.

Their guidance is specific enough to hold a provider to. Assign the Global Administrator role to fewer than five people, keep total privileged role assignments under ten, and pick from the 65-plus built-in roles for anything narrower. There is a whole reference page listing the least privileged role for each individual task. Almost nobody reads it. Read it anyway. An afternoon of work, and it removes an entire category of argument from the engagement before the argument ever starts.

Here is how the access side gets set up in practice.

• Every engineer who touches your tenant has a named account. Not a shared provider login. If you cannot tell from the audit log which human made a change, you do not have an audit log. You have a rumor.
• Two cloud-only emergency access accounts, permanently holding Global Administrator, assigned to no individual. Microsoft calls these break-glass accounts. Credentials split so neither side can use one alone.
• Your internal person keeps admin rights. This is the part people get wrong out of some instinct that outsourcing means surrendering. It doesn’t. Their scope narrows to what they actually run.
• BitWarden is our recommended system for the shared credentials, with separate collections rather than one vault everybody can see.
• Access gets reviewed on a schedule and things get removed. People change teams. Permissions accumulate quietly and never fall off on their own.
• One more that gets skipped constantly. When an engineer leaves the provider, that is your offboarding event too, not just theirs. Ask how you get told.

The Day Somebody Starts and the Day Somebody Leaves

Onboarding is where co-managed shows its value fastest. Offboarding is where it fails most expensively.

The failure is almost never technical. HR tells the internal IT person on a Thursday. The internal IT person is out that week. Nobody tells the provider. The account stays live for weeks, and it surfaces during the next insurance renewal questionnaire, which is a bad place to learn it.

CISA’s goal 3.D covers exactly this, and the wording is worth reading closely because it is broader than people expect. It asks for a defined and enforced administrative process to offboard staff, and it spells out that staff includes contractors and vendors, with physical tokens and badges returned and all access revoked. Not most access. All of it.

The fix is unglamorous. HR’s trigger goes to the shared queue, not to a person’s inbox. A queue does not take vacation. It does not get sick, forget, or leave on a Friday afternoon with the thing still open in a browser tab it never came back to, and that single routing change closes most of the gap on its own.

From there the work splits cleanly, and the order genuinely matters. Microsoft’s own removal runbook is seven steps, starting with blocking sign-in and ending with deleting the account, and there are two retention facts in the middle of it that decide who owns which decision.

• Block the sign-in first. Everything else can wait. That one cannot.
• Once a license is removed or deleted, Microsoft keeps the mailbox, contacts, and calendar for 30 days and then deletes them permanently. That clock is why the mailbox decision is a business decision, not an IT one.
• Remove the license but leave the account in place and the OneDrive content stays reachable past the 30 days. Delete the account and you are inside a 30-day window to restore it.
• Your team decides who inherits the mailbox, whether the address forwards or converts to shared, and what happens to the phone and the physical keys.
• My team executes the tenant work, wipes the mobile device, hands the OneDrive and Outlook data to the person you named, and confirms it in writing the same day.

Onboarding runs the same shape in reverse, and it is far less dramatic. Your team knows the new hire’s role, which shared drives they need, which line-of-business license to buy. We build the account, the security groups, the device, and the software load against a standard build sheet. Somebody signs off that the person could actually work on day one. The whole reason to write it down is that the build sheet is what stops your environment drifting into a fleet of one-off laptops nobody can support.

What Actually Changes About Your IT Person’s Week

Ask them directly before you sign anything. Then listen to the tone, not just the answer. It will tell you more than any proposal will.

What leaves their calendar is the work that was never really their skill set. Patch nights. Watching backup jobs complete. Being first look on every endpoint alert, including all the ones that turn out to be nothing. Carrying the pager for a firewall somebody else configured years ago. And the heaviest one, being the single person who knows how anything is wired, which sounds like job security right up until they want two weeks off.

What fills the space is more interesting work and more of it. Vendor relationships they already own. Project work that has been sitting in a folder for a year. Sitting between the business and the technology and translating in both directions, which is the part of the job that is genuinely hard to hire for. Very hard.

Now the cost. There is one. Pretending otherwise is how these arrangements get oversold.

They have to document. Every quick fix that used to happen at somebody’s desk now needs a ticket note so the other team is not troubleshooting a change nobody recorded. Written change requests replace walking over and doing it. Some people find this liberating and some people find it insulting, and you would rather know which kind you employ in week two than in month five. The other adjustment is subtler. Somebody outside the company is now looking at the environment they built, weekly, and having opinions about it. That is uncomfortable for about a month. It stops being uncomfortable roughly when the first thing they flagged turns out to have been worth flagging.

What Gets Reported and How Often

Two rhythms, and they do different jobs. The operational one is a standing meeting every two weeks with whoever runs IT on your side, to walk the open issues and anything in flight. Not a status theatre, and not long. It exists because the things that quietly rot in a co-managed arrangement are the ones neither side thought were theirs, and a fortnightly pass catches those while they are still small. In between, your person reaches out whenever something escalates internally or something new lands. There is no barrier there, and there should not be one.

The reporting underneath that should be dull and continuous. Dull is the goal. Ticket volume by category, response times measured against the standard rather than described in adjectives, patch compliance, backup success rates, restore tests that actually ran, endpoint alert counts and what happened to each one. Available whenever you want it, summarized monthly. None of that needs a meeting.

The strategy conversation is a different animal and it should not be stapled to the operational one. vCIO strategy and roadmapping is about budget, lifecycle, renewals, and what your business is planning to do next year, and it works badly on a fixed short cycle because the business rarely produces material to discuss on that schedule. Nobody enjoys a recurring meeting that exists to fill a slot. Ours run closer to annual, and get pulled forward the moment something real lands, a lease, a renewal, a hiring plan, or an end-of-support date with teeth in it.

One cadence I would insist on though. The responsibility split itself gets re-read, and every uncategorized ticket from the period gets used as evidence that a row is wrong. Amend it. A split document that has not changed in two years is not stable. It is ignored.

Questions I Get on the First Call