Business agreements between organizations go far beyond a handshake, requiring formal contracts that define service expectations, confidentiality obligations, partnership terms, and security requirements. This content covers the full range of common agreement types used in IT and business partnerships, along with the individual terms and clauses that give those agreements their legal and operational weight.
Agreement Types & Terms
Once we're in agreement on how we're going to do business together, the next step is to get it all in writing, and there's several different agreement types that are common out there.
At one point in time, as soon as we agreed upon the terms, all that was needed to do business together was a firm handshake. That's no longer acceptable. You bring on too much risk, and nowadays you really need some sort of contract. You need to put it in writing.
One of the reasons why it's so critical to put it in writing is because when it's in writing you have a firm understanding of what the expectation is, and this could raise concerns by actually seeing it when it is in writing, when you are setting those expectations. For that reason, many times we end up going back to the negotiating phase to recreate the contract. So there's kind of this loop that happens during this negotiating of the contracts.
One of the common things that we outline is a service level agreement, or an SLA. This gives us a standard of what service level we're going to achieve and what would be considered substandard. It also outlines what the repercussions are if you don't reach those service levels that you are guaranteeing. So this outlines exactly what the level of service is that you're going to get.
In almost every contract that I sign, in the partnerships that I create, we create some sort of non-disclosure agreement. The non-disclosure agreement outlines exactly what the expectation is as far as what is confidential information, and makes sure that you're not going to disclose confidential information to other parties - that whatever is discussed and whatever data is interchanged is not going to be discussed or exchanged with any other entity.
The work order or statement of work outlines what work is actually going to be performed. It outlines what the expectation of that work is. Maybe things like delivery dates are going to be in there, maybe things like cost of the project is going to be in there. So it's going to outline all of the expectation on what's going to be delivered and how it's going to be delivered.
One of the problems with this work order right here is we could have a ton of different work orders that we create, or maybe a ton of statements of work that we create, and to have a huge long contract for each one of those work orders might not be the best use of our time as we pour over the details of those. We might want to just set up how our organizations are going to work together from an overall perspective, from an umbrella perspective, in a different document. That's what the master service agreement, the MSA, is for.
The MSA talks about what the payment terms are going to be, how long it's going to take to get paid and what the payments are going to look like, and perhaps other things like the non-disclosure agreement gets worked into the MSA. So there's a lot of information that goes into this MSA of just how we're going to partner together, and then individual projects, that's going to be the statement of work there. Like I say, there's a lot of things like the NDA that get worked into the MSA. The SLA, the service level agreement, could be a separate agreement, or it could be worked into something like the work order there, perhaps maybe even the MSA.
The interconnection security agreement, or ISA, is established when you have two systems that are connecting together. So for instance, let's say we have two different companies and they're connecting their systems together, their IT systems or their infrastructure together. Then what they need is an ISA, an interconnection security agreement, that establishes what the agreement is of connecting those two systems together and how you are going to approach security with them.
Since privacy is such a huge topic nowadays, and there's lots of laws and regulations around privacy, we could address that separately in a privacy level agreement that addresses how privacy is going to be handled.
An operational level agreement is more of an internal document. When it talks about operational, it's how you are performing internally, and more specifically it's the agreements between departments, and how you're going to, within a company, within an organization, be able to provide services within that company. So it's an operational level agreement.
Now, many companies are just going to operate the same way: what they do is they just put out what their policies or agreements are and you have to agree with it. For instance, Microsoft is a big company, and for them to negotiate contracts with every single user would be unreasonable. So they just have their standard set of: these are the agreements that you're agreeing to for our services.
A lot of software vendors have some sort of maybe software licensing, or terms of service, or terms of use, or terms and conditions, and they go by many different names. There might be some nuances between these, little minor differences, but essentially it's all the same concept and same idea - that if you use our services then you're agreeing to this. And then by you actually giving the credit card or setting up the account or whatever the case may be, you're agreeing to whatever these terms of service are.
If you're creating a partnership with another company, then you might be wanting to set up a whole partnership document. So there is a business partner agreement, a BPA. This sets out how you're going to partner, how you two are going to work together in this partnership.
Now, you might not be quite at the stage where you have everything filled out, but the problem is, if you wait too long to really document things out, then this could be problematic and you might be on completely separate pages. So what you might want to do is start out with a memorandum of understanding. This memorandum of understanding is not legally binding. What it is, is you just write out what it is that you're agreeing to, to make sure that when you get further down the road you aren't going to run into problems. It's a good way to start out a relationship and establish what the agreements are.
Then there's something in between: that's a memorandum of agreement. The memorandum of agreement, the same way, it's not necessarily as legal as the legal partnership agreement that you create, but it does have legal backing to it. So you write down what your agreement is and how you're going to approach this partnership, and sign it just to get things kicked off.
No matter what kind of business that you are, you probably are going to want a privacy policy. This is something that most businesses are going to want to have. If you have a website, you're probably going to need to post your privacy policy on that website, and it's just how your company approaches privacy. Even those who are visiting your website need to know: are you going to take my information, are you going to record it, are you going to sell it to somebody else, are you going to keep it securely? They're going to want to know those things. So the privacy policy is something that, if I visit your site, I should be able to go and look to know what you would do with any information that you gather from me.
Within a contract we have individual agreements. We call each one of those individual agreements a term. A term is what we are agreeing upon, and there's several different types of terms that are often incorporated into these contracts.
One of them is rules of engagement. The rules of engagement would be for something like if we're doing pen testing, and what are going to be the rules that we're going to set forth - maybe what the schedule is, or how the process is going to be, but what are the rules for that engagement going to be.
In some of these agreements we're going to want to set up a right to audit. A right to audit means that we want to go in and do an audit of their systems, or of their processes, or whatever the case may be. This might be on an ongoing basis. For instance, maybe we are setting up a contract with a company, we do an initial audit, and now in the future we want to make sure that they're still doing what they said they were going to do, that they didn't do it just once and that they're continually doing it. And so we may set up a right to audit in the contract so we can audit them further down the line.
There are times also that we may require a source code escrow, a place that we're going to keep the source code, so if something happens to one of the entities we can go in there and grab the source code and not hinder our business.
Let me get further into source code escrow. Let's say there's two companies that are partners. In fact, this is actually one of the things that I had to do, because we were a company that sold educational software and we were partnered with another company that wanted to sell our product. Well, as we were developing this partnership, they were really relying on our code. We didn't want to give them that code because it was a valuable asset to us, and we didn't want them to take that code and maybe use it on their own, or do something with it that we didn't want them to do, develop it on their own.
And so what we would do is, we agreed upon that we would keep a copy of the code in an escrow. I would copy the code down and I would deliver it to escrow - somebody would actually come pick it up and it would be held in escrow. Escrow is a third party that's holding on to this. And then if something were to ever happen, like our company went under, then this other company could go to escrow and show that the company went under, get the source code, and then they are still viable. That way they can still do business even if we were to go under.
It's a way of protecting risk here. It's protecting us, because we're not just handing over our code.
TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.
Explore free tools and programs →