What to Keep In-House No Matter What

Clause 2.1 says "all IT functions". It is a tidy phrase in a tidy contract: forty pages, numbered, with a schedule of response times at the back. The person reading it is Tomas, who is the IT department at Acme. He has reached the clause at 12:40 while eating lunch at his desk. Across the yard, the warehouse scanner has died again. Tomas knows without looking up which supplier to call and what the contract number is. He knows the spare is in the gray cabinet by the loading door. Clause 2.1 does not know any of that. Clause 2.1 is about to own it anyway.

Nobody writes "all IT functions" to be sinister. The provider wrote it because a clean scope is easier to price, and the director signed it because it sounded complete. The trouble is that some functions can be performed by someone else and must still be owned by you. "Owned" has a precise meaning: you make the decision, you hold the record, and you could carry on if the other party vanished on a Tuesday. This is the second article in our Sourcing Support series. The first, The Three Sourcing Models, Plainly, defined the models. This one is about the line that does not move whichever model you pick.

It covers the five things to keep in-house no matter what, with a section on each and what goes wrong when it leaves. Next come the owner-of-record idea, keeping a copy quarterly, and the four clauses to insist on. A war story from a bank branch follows. The article ends with a checklist to fill in against your own contract before anyone signs it.

The Five Things to Keep

A managed service provider, or MSP, is an outside company that runs some or all of your IT for a recurring fee. An MSP can do almost all of the work. What it should not hold is the decisions and the records that make the work yours. There are five of them. First are identity and access decisions. Next are security decisions and the authority to declare an incident, then vendor and contract relationships. The knowledge of how the business actually works follows. Last are the data and the records, including the ticket history.

The common thread is that none of the five is a task. Each is either a decision (who gets access, whether this is an incident) or a record (who supports the scanner, what happened on ticket 4471). Tasks can be rented by the hour. Decisions and records are what the hour is spent on, and they belong to the organization whose name is on the building.

The sections that follow take each one in turn: what it is, why it has to stay, and what happens when it does not. The last part is the useful part. Every item on the list is there because someone, somewhere, found out the hard way.

Identity and Access Decisions

Identity and access decisions are the answers to four questions. Who gets an account? Which groups and systems does it join? Who may hold administrative rights? When is a leaver's access removed? The MSP can create the account, add the groups and press the buttons. The decision to do so is yours, made by a named person and recorded.

Keep it because identity is the key to everything else. Whoever decides who can see payroll decides who can see payroll. An auditor who asks "who approved this administrator account" expects a name from your organization, not a ticket number in someone else's portal. Keep the leaver process in particular. The list of who has left and when their access ended is the first thing an audit asks for and the last thing a provider thinks to send.

When it leaves, accounts get created on the strength of an e-mail from "a manager". Administrative rights accumulate because removing them was never anyone's ticket. Leavers keep working accounts for months. None of this is the MSP's fault. They were asked to perform a task and did. The decision was supposed to be somewhere else, and it was nowhere.

Security Decisions and Incident Declaration

An incident, in this sense, is a security event serious enough to need a response beyond the normal queue. Examples are a compromised account, a device encrypting files, and data where it should not be. The decision that an event is an incident and the authority to declare one stay with a named person inside your organization. So do the decisions that follow (disconnect the site, reset every password, tell the regulator).

Keep it because the provider's incentives and yours diverge at exactly this moment. A declared incident is extra work, a bad line in the monthly report, and possibly a conversation about whose fault it was. A provider that is allowed to decide whether to declare will, in good faith, tend to wait for more evidence. You also know things they do not. You know that the regulator wants to hear within a fixed number of hours. You know that the finance director is on a plane and that the odd login was from the auditor's laptop.

When it leaves, the symptoms are a ticket. An engineer at the MSP sees unusual logins at 14:10, opens a normal-priority ticket titled "investigate", and works it in order. The ticket is picked up on Thursday. The declaration, when it comes, is two days late and made by the wrong organization. Write the rule the other way. The MSP must tell your named person within a short, fixed time of suspecting anything, and your person decides. The MSP will like this rule more than you expect. It takes a decision off their desk that was never theirs to make.

Vendor and Contract Relationships

Vendor relationships are the contracts, account numbers, named contacts and renewal dates for every supplier that keeps the business running. That covers the internet line, the line-of-business application, the scanner maintenance contract, the printer lease, and the domain names. The MSP can call the supplier on your behalf. The contract, the account, and the relationship stay in your name and in your register.

Keep them because the MSP is itself a vendor. Letting one vendor hold all the others puts a single company between you and everyone who can fix anything. It also makes leaving nearly impossible: the day the contract ends, you need to call eleven suppliers and you do not know their names. Keep a vendor register. It is one table listing each supplier, what they support, the account or contract number, the named contact, and the renewal date. Review it quarterly. Renewal dates have a habit of arriving on a Friday in a month nobody checked.

When it leaves, you find out the first time a device dies and the person who knows who supports it is on leave. The war story later in this article is that, exactly. The register took Lena at Bluewater Bank an afternoon to build from invoices, and it has not left the bank since.

The Knowledge of How the Business Actually Works

This knowledge is the second of the two kinds the first article described. It is not how the technology works, which any competent engineer brings along, but how your business works. Which three accounts must never be touched. Why the label printers have fixed addresses. That the month-end run must not be interrupted between the twenty-fifth and the first. That "the scanner" means the one by bay three. It was learned on your premises over years, and it is the only knowledge that cannot be hired.

Keep it because it is the part of IT that is actually yours. The technology knowledge belongs to the trade; the business knowledge belongs to the business. Keep it in two places. One is a knowledge base you own, where every fix lands whoever made it. The other is an estate page, one page per site listing what is there, who supports it, and how to reach them. The provider may use their own documentation tool as well, and will. Do not let the estate page live only there. It will be beautifully formatted and, one day, beautifully gone.

When it leaves, it leaves in one piece, on the last day of the contract. The new provider or the new in-house desk then spends its first six weeks relearning what the old one knew. The knowledge clause in the next section is the fix. The habit behind the clause is the real fix: nothing is fixed until the fix is written down somewhere you hold the keys to.

The Data and the Records

The records are the ticket history, the knowledge base, the configuration backups, the asset list, the logs and the monitoring history. They are the memory of the desk and the evidence of what was done. Whoever holds them holds the ability to answer "what happened" for every audit, dispute and handover for years to come.

Keep them because the alternative is a portal you do not control. When the contract ends, the export you get is whatever the provider's tool produces. Sometimes it is a clean file, sometimes a printout three thousand pages long, sometimes a spreadsheet of internal identifiers with the ticket text missing. The ticket that was deleted is gone from everyone's history, including yours. I have received one of those exports. It was not a document; it was an apology with columns.

When they leave, the next provider starts from nothing and the audit cannot be answered. The known-error list, the catalog of problems you have seen before and how to fix them, then has to be rebuilt from memory. The remedy is in the next two sections: own the record, and if you cannot own it, hold a copy you could run the desk from.

Owner of Record: Performed by Them, Owned by You

The owner of record is the party that decides the policy for a function, holds its records, and could carry on if the other party disappeared. For every function in the contract, write down two names: who performs it, and who owns it. The two can be different, and for most of the list they should be.

Take patching. Performed by the MSP: they run the schedule, test, deploy, handle the failures. Owned by you: you decide the maintenance window and hold the monthly report showing what was patched and what was not. You could hand the schedule to a new provider tomorrow because the record is in your folder. Take backups. Backups are performed by the MSP and owned by you. That means you decide what is backed up and for how long. You witness a restore test every quarter and keep the record of it. A backup nobody has restored from is a hypothesis.

The owner does not need to be technical. The office manager can own the vendor register and the leaver list; a director can own incident declaration. What the owner needs is to know they own it, to hold the record, and to be the name an auditor is given. I have watched this idea turn a bad contract into a workable one without changing a single response time, because the argument was never about speed.

Keeping a Copy, Quarterly

Keeping a copy means that once a quarter, on a fixed day, you take an export of everything that lives in the provider's systems. You store it on something you control. The ticket history as a plain file with the ticket text, not only the identifiers. The knowledge base. The estate page. The vendor register. The patch and backup reports. A sealed export of any credentials the provider holds on your behalf. The copy is the test of every clause in the next section. A clause you cannot test quarterly is a clause you will test at exit, under pressure.

Here is what a quarter's copy looks like at Kestrel Payroll. Priya is the owner of record for the lot and the desk is run by an MSP. First Monday of the quarter, 09:00: the ticket export arrives as a plain file, 1,140 tickets for the quarter with their full text. Priya opens it, checks the last ticket number matches the one she saw on Friday, and files it by 09:12. By 09:25 the knowledge base export, sixty-two articles, is in the same folder. By 09:30 the estate page is printed to a file: thirty-seven lines, each a device or a service with its supporter and contact. By 09:45 she has read the vendor register for renewals due in the next ninety days and found two. The folder is on the Kestrel file server under Sourcing, in a subfolder named for the quarter. The whole job is forty-five minutes, and it has been run every quarter for two years. That is why she knows the export works.

Take a help desk that keeps the ticket history on your own server, exports its reports as plain files, and never lets a ticket be deleted. It keeps the record in your hands whoever does the work. QuerySolv is self-hosted and works that way: every ticket action is recorded, nobody can delete a ticket, and reports export to CSV. We sell it, so weigh that; the principle holds for any tool you control.

The Four Clauses to Insist On

Four clauses turn the five things from good intentions into terms the provider has agreed to. Ask for them before signing, because adding them at renewal is a negotiation and adding them at exit is a plea.

• Knowledge handover. Every fix is documented in the customer's knowledge base within one working day of resolution. The estate page is maintained in the customer's format. At exit, all documentation is delivered in that format, not the provider's.
• Data export in a usable format. The ticket history, with full text and attachments, is exported quarterly to the customer as part of the fee. It is in a plain file format readable without the provider's software. The customer may request an export at any time.
• Named contacts. A named lead engineer and a named service manager, with direct phone numbers, replaced in writing when they change. A shared mailbox is not a contact.
• Exit assistance. The provider gives ninety days of cooperation after the end date, on a written schedule. Knowledge, credentials, open tickets and data are handed over in the first thirty days. The provider's engineers are available for questions until the end.

Each clause maps to one of the five things. Knowledge handover protects the business knowledge. Data export protects the records. Named contacts protect the vendor relationship with the MSP itself. Exit assistance protects all five on the day they are most at risk. The identity and incident decisions need no clause, only a sentence: "performed by the provider; decided by the customer's named owner."

A Short War Story: Two Days at Bluewater Bank

Bluewater Bank's branch network was run by an MSP, and the MSP held the only list of which supplier supported which device. On a Monday at 08:20 the document scanner at the Harbor Street branch stopped feeding, and the branch raised a ticket. The engineer who had set the scanners up, and who knew the maintenance supplier, was on two weeks' leave. The engineer who picked up the ticket spent Monday searching old tickets for the supplier's name and found it on Tuesday morning. The engineer then needed the serial number and the maintenance contract number, which were on an invoice at the bank. The scanner was swapped at 15:00 on Tuesday, and for two days the branch sent its documents to the next branch by courier. Nobody was blamed; the engineer on leave had done the work well, and the engineer covering had done everything the ticket allowed. The next month the estate page came in-house. Lena, the branch operations manager, built it from invoices in an afternoon, and the MSP works from a copy.

I keep the Bluewater story because the fix was so small. One page. The provider had never been asked for it, and the bank had never known it needed it.

The Keep-In-House Checklist

Fill this in against your own contract, one line per function. The two columns that matter are "owned by" and "copy held where". If either is blank for any row, that row is the next conversation with the provider. If both are blank for most rows, that is the conversation with the director.

Clause 2.1 can still say "all IT functions". Add one sentence after it: "performed by the provider; owned by Acme as listed in the schedule," and attach the table. The provider will not mind. The good ones will be relieved, because the sentence tells them where their job ends, which is something the forty pages never did. Then Tomas can finish his lunch, call the scanner supplier, and know that when the contract ends the number will still be his. Working With an MSP Without Losing the Plot takes the relationship from here.

Frequently Asked Questions