Technology providers need to consider how they approach contracting their services to improve their risk. The team at Wotton + Kearney and SherpaTech unpack how legal and insurance work together to protect customers and suppliers from exposures.
Featuring: Stephen Morrissey, Nick Martin and Christy Mellifont (Wotton + Kearney), with Andrew Bremner and Tim Stephinson (SherpaTech)
Recorded: 3 December 2024
Length: 57 minutes
Key takeaways
- Christy explains that a clear, complete scope is the best way to avoid disputes. In one ERP matter, a $1 million, one-year contract has grown to over $5 million and more than five years because the customer made 91 change requests.
- Andrew's position is that MSPs should not complete their customers' cyber insurance proposals. Help explain the IT side, but the customer must complete and sign it, because a misrepresentation could lead to a PI claim against the MSP.
- Many MSAs were last reviewed four or five years ago while services have changed dramatically. Nick's advice is not to let them gather dust: review them regularly so scope, risk and the law stay current.
- Christy notes that limitation of liability clauses are not a silver bullet. Unfair contract terms laws can apply if either party is a small business, they may not work against Australian Consumer Law misrepresentation claims, and they must clearly name negligence if you want to exclude it. They are still better to have than not.
- Tim and Andrew recommend a combined PI and cyber (IT liability) policy so there is one insurer and one strategy, rather than two insurers pointing fingers at each other. As a rule of thumb, Andrew says it costs about 20% more.
- Nick says to plan the exit at the start: a paid transition-out period, how customer data is returned or deleted, and which clauses survive. He also warns against "agreeing to agree" on terms after signing.
- Customers need their own cyber insurance. The panel says the 24/7, legal-led incident response is where much of the value lies, and Steve describes an MSP with PI but no cyber cover that stopped trading within two weeks of a ransomware attack.
Transcript
Stephen Morrissey: Before we kick off today, Wotton + Kearney acknowledges the traditional owners of the land on which we virtually meet, and we pay our respects to their elders past, present and emerging.
For those who don't know me, my name's Steve Morrissey. I'm a partner in Wotton + Kearney's technology team based in Sydney. I'm pleased to be joined today by tech and IT insurance specialists Tim Stephinson and Andrew Bremner from SherpaTech, as well as Christy Mellifont, special counsel from Wotton + Kearney's Melbourne office, who specialises in technology liability. And Nick Martin, special counsel from Wotton + Kearney's Sydney office, who specialises in technology contracting, and you'll hear a lot from him today.
If you've got any questions, hopefully we'll have some time at the end, so please feel free to submit them as we go along. Today's session will offer some practical tips on technology contracting, as well as ways to improve your insurance risk profile and manage technology risks generally.
So kicking things off, Nick, I might start with you. Starting at the pre-contract phase, when an IT provider is responding to an RFP or an RFQ, how should you approach writing the proposal or response? Can you just put in whatever you like, knowing that the customer will never be able to rely on it?
Nick Martin: In short, no. Probably not a good idea. It may be tempting to chuck in anything you want, promise the stars, and hope to rely on the entire agreement clause in the final contract. But actually there are a couple of ways that a customer will try and hold you to those promises and representations you've made.
They might seek to incorporate all pre-contract documents into the contract by reference, in which case, yep, they're part of the contract. Or they may seek to translate or reproduce some of the content in those documents as substantive content in the agreement itself, most likely in the schedules.
Tim Stephinson: So how would it go with sharing general marketing material? Say I've been given all my vendor's standard fact sheets or the capabilities of all their products, and I throw all of that in. Could that be included in the contract?
Nick Martin: Look, it could be. I think most vendors would be pretty wary of having that sort of marketing material included in any format, just because it's not really meant to be relied on. That's more just a foot-in-the-door sort of thing. But for the more detailed material about the solution and what's being promised that they can deliver, if they get the gig, I think it's safe to say that will find its way into the end agreement one way or the other.
Tim Stephinson: So don't oversell, right?
Nick Martin: Yeah. You'll be held to it one way or the other.
Stephen Morrissey: Okay. So assuming you've won the engagement, turning to the contract now, how important is it to define the scope clearly and accurately, and what are the risks of not doing that?
Nick Martin: I think Christy's got this one.
Christy Mellifont: From a disputes perspective, which is where I come from, the scope is really, really important. It should set out clearly and comprehensively what the customer is buying and what the vendor or provider needs to deliver.
The reason it's so important is because we see a lot of matters where the customer perhaps didn't really know what their requirements were before they went into the contract. Those requirements only crystallised after the scope had been agreed, and that results in repeated change requests. And then we see a lot of disputes over the additional costs associated with those change requests.
For example, I've got a matter at the moment with an ERP solution. The contract was for a cost of $1 million and a contract duration of one year. It ended up costing over $5 million and it has lasted over five years. It's still not done, because the customer made 91 change requests.
So you can see how these claims can become really expensive from a legal perspective, because forensically, to defend that claim on behalf of the provider of the ERP, we have to show each change request, the additional costs associated with it, and how we say that's payable under the contract. So from an avoiding-disputes perspective, scope is key.
Stephen Morrissey: Okay. Well, we talked a little bit before about one type of proposal. Moving to a different type of proposal now, being a cyber insurance proposal. A question for the SherpaTech guys: should MSPs complete their customers' cyber proposals?
Andrew Bremner: I'll jump in first. Thanks, Steve. The starting position is no. We get asked this all the time by our customers: should we be completing proposals, particularly cyber proposals, on behalf of our customers? And really, the position is no.
However, we often hear the customers saying, "But we don't understand our technology. You look after our technology." There's a real concern that people transfer the risk, in their own minds, to the MSP. It's a major concern and we see this increasing with time.
What we do suggest to our customers, and you guys probably have a bit of a view on this, is certainly assist where there are questions. Perhaps have a discussion and help explain what the IT component or provision of services is. But the customer needs to complete that proposal and sign off that proposal themselves.
It's also a great chance to make your customers aware that their data is typically their responsibility. It's not the responsibility of the vendor or the MSP in that case. They need to own that, and their cyber policy is built to protect them in that instance. But they need to own the process.
Stephen Morrissey: In terms of the MSP, if they get blamed for misrepresenting the proposal, then there's a chance of a professional indemnity claim against them, which is a concern. So that's one way MSPs and IT providers can improve their risk profile: don't fill out their customers' cyber proposals.
Another question for the panel, probably to the SherpaTech guys first. Is there anything else that they can do to improve their risk profile?
Tim Stephinson: One of the biggest things we see, and it's actually not in our lane, is their MSA. That's why it's great to have Wotton + Kearney in the room today, because we tell a lot of people, when we look at their risk, that legals typically come before insurance. So we like to lean on something that we know is stable and solid, and that's the MSA, if they get it right.
You'd obviously see it when you have claims, representing underwriters. That's the pillar that typically comes out first: what does the contract say?
Andrew Bremner: Yeah, absolutely. Often when we do our insurance reviews with our customers, we say, "When was the last time you reviewed your MSA?" And almost without fail, it was four or five years ago. And in those four or five years, their services had dramatically changed. The scope's not up to date. It's such a vulnerable space.
Stephen Morrissey: And the law changes as well. We'll hear about that a bit later on.
Nick Martin: Absolutely. Technology agreements don't exist in a vacuum. They have to keep pace with relevant case law and legislation. So it's absolutely crucial.
Andrew Bremner: You need the help from the professionals.
Christy Mellifont: It's a common problem. In one of my matters at the moment, acting for an MSP, they've had this customer for over 10 years. There's a service agreement that was signed over 10 years ago, but no one has the final executed copy. Where is it? And the customer relationship has evolved.
We're going to talk a bit about how you can have limitation of liability clauses in the contract and things that you can rely on. But in order to rely on them, we need to demonstrate what the contract is. So it is really important that it keeps pace with the customer relationship.
Andrew Bremner: Sorry, jumping in. The MSA is certainly one. Another one is that, as an IT service provider or an MSP, your customers need a cyber insurance policy. Why? Because when they have a cyber incident, they reach for the 24/7 incident response within the cyber policy first, rather than your professional indemnity policy. So it's something that can be done, and it can often be incorporated into the MSA, which you guys know far better than us. We're seeing the more mature MSPs doing that.
Stephen Morrissey: Yeah, I think that's right. As Christy was saying, the failure of a lot of these contracts to keep up with the services being provided is a massive problem.
Another problem that I want to turn to now is ambiguous or unclear drafting and obligations. So Nick, where you've got both legal terms and conditions and back-end schedules and so on, do you still see examples in your work where things aren't as clear as they could be? And how does that manifest into a problem?
Nick Martin: Oh, look, all the time, to be honest. Not just around scope, which Christy's already talked about, but even around the actual obligations of either party. It's a bit of a cliche, but you can't overestimate the virtues of drafting in plain English, plain language, just to avoid the issues that arise from uncertainty, ambiguity and all the rest of it.
The idea is that anyone should be able to pick up the contract and understand it. Even if it's really complex ideas, they need to be in a digestible form. If you follow the rules, you should be okay. I'm sure we've all heard them: active voice, not passive voice, avoiding repetition, not having clauses broken down into 75 different sub-clauses and all that. It's got to be understandable.
If you want to be able to rely on the document in the event of any dispute or disagreement, you don't want to end up before a court saying, "We don't really know what the parties meant." Plain English drafting has been around for quite a long time now, but unfortunately people still don't seem to understand how important it is. No lengthy phrases they don't need.
Tim Stephinson: How far should people go, if they're doing a certain scope like general office services, in calling out the things they don't do, maybe incident response or security services or other bits and pieces? How far do I need to go? If I said I'm going to do your Office 365, do I need to say I'm not managing your network and I'm not managing your security? Or is that logical, or do people assume that one does all?
Nick Martin: No, I think most service providers tend to take the approach that anything we don't say we're doing, we're not doing. To put it another way, this is pretty much an exhaustive list of the things we're going to do, and everything else is excluded. It's too hard to list absolutely everything that you are not going to do, so just take the opposite approach.
Tim Stephinson: Is incident response something people should call out if they're not doing it for a customer? Like if they're doing their IT management, should they call out that they're not doing incident response?
Nick Martin: I guess that one is fairly fundamental. That's probably worth including in the contract as an exception. But it's the greyer areas where you don't want to be in the position of, "Oh, well, we thought you were doing that." And it all comes down to that absolutely tight scope document, and what we said at the start about what the proposal said. Did you say you were going to do this pre-contract?
Stephen Morrissey: Yeah. Frankly, from a claims perspective, I wouldn't mind people doing it your way, Tim. Christy might have something to talk to as well, but we've got examples of MSAs talking about, for example, security administration obligations. Well, what does that mean exactly? Backup management: what does that mean? Virtual machine management, in a case where a cyber incident happened because of a vulnerability exploited through a virtual machine. A lot of time, money and angst has been spent in those cases trying to work out what a couple of little words in a contract mean.
Tim Stephinson: We get that raised a lot by people trying to understand underwriters' definitions of technology activities. And we explain the why: the reason underwriters are asking is that they want you to volunteer everything you do, so they can figure out whether it's covered or not. Sometimes the nuancing of those things can be really important.
Especially on the insurance side, technology providers need to be very clear about their definition of those things and bring them forward for everyone to understand. And if that is then reflected in the technology contract wording as well, really good, because you get alignment between all three of those areas.
Stephen Morrissey: Yeah, that's good.
Andrew Bremner: The trouble is the technology itself is evolving faster than the contractual side, including the insurance side, that's there to protect it. It's always running behind. One of the big concerns that we are seeing as well is particularly large customers getting their MSPs to take on more risk, more exposure, on new technologies and also on keeping the lights on, and transferring that risk, or attempting to transfer that risk. Sorry, it's a slightly different point, but I think you're coming on to it.
Then circling back to those individual points: in the proposal form, be very clear about what activities you undertake. It reduces the risk of the insurer denying the claim by saying, "You didn't tell us about that."
Tim Stephinson: We also get better premiums when we're fully transparent with underwriters. It's a common myth that if you tell them everything, it's going to cost more. In most cases, the more we tell an underwriter, the better priced the premium is, because they understand the risk better.
Stephen Morrissey: I imagine it could also be the difference sometimes between getting insurance at all.
Tim Stephinson: Absolutely.
Stephen Morrissey: Completely agree. Christy, touching on something Andrew just mentioned in terms of risk mitigation under technology agreements, what are some of the contractual mechanisms that can be used to apportion risk in a tech contract?
Christy Mellifont: As we said before, the contract is where we look first to work out how it apportions risk when a dispute arises. That usually happens in one of two ways. The first is a limitation or exclusion clause. You'll often see those where they impose a cap on the amount of liability that one party has for the other's loss. Sometimes that's referable to fees, for example a month of fees or a multiple of fees. And sometimes those liability caps will have carve-outs, so exclusions for certain types of claims or loss. You'll also see clauses which exclude liability for things like loss of profit or indirect or consequential losses.
The other provision is indemnities, where one party to the contract agrees to make the other party whole for any loss they suffer, irrespective of whether there's been a breach of contract or negligence on the part of the first party. Those are the two ways you see most commonly.
I think the takeaway for preparing those clauses is that they should try to deal with risk in a fair and reasonable way. That's your opportunity at the outset to do that fairly. And to pick up on your point earlier, you do see one party to the contract trying to use those mechanisms, for example an indemnity, to really transfer the risk. Nick's probably the person to talk to about this.
Nick Martin: I think we talk about it a bit later on, around liability and negotiations and how you can approach them. Spoiler alert: it's not about getting the best possible deal you can and screwing the other side. It's really about getting somewhere that both parties can live with. But we'll chat about that a bit later on. It's absolutely a big cause of angst and sleepless nights. I think people freak out when they see the word indemnity or liability limitation.
Tim Stephinson: One of the tips we have for our customers is don't be afraid to bring the underwriter into the conversation. When you are going through those contractual negotiations, make sure the underwriter's comfortable with it. Go through your broker and actually take them the problem as well.
We've seen some really good responses from underwriters that actually help our customers have that negotiation and find that fair place in the middle. Sometimes the contracting party can be very aggressive, obviously trying to get the best thing for their side, and the underwriter can sometimes help the technology provider bolster their arguments as well, assist with the negotiation, and get the deal over the line at the end of the day.
Stephen Morrissey: Christy, do you think limitation of liability clauses and so on are a silver bullet, the be all and end all? Or are there certain circumstances where they might not be as effective as the parties intended?
Christy Mellifont: Whether they're enforceable or not is really dependent on context. For example, if the other party to the contract is a small business, the contract might be subject to the unfair contract terms regime, which means the court has more power to find that bargain unfair.
Tim Stephinson: Do you see that going in favour of the smaller entity?
Christy Mellifont: Typically, that's right. That's the purpose of the legislation: to protect small businesses. One of the things the court will look at in that case is whether the limitation or exclusion of liability is reasonably necessary to protect the interests of the parties.
Tim Stephinson: Does it matter whether it's written on the small business's paper or the larger organisation's paper?
Christy Mellifont: It doesn't, no. If either party is a small business, then this regime potentially applies.
The other thing is that we often see claims for misrepresentation against technology providers, and they're usually made under the Australian Consumer Law. There's some inconsistent authority on whether limitation of liability clauses work on those types of claims under the ACL, and I think the better view is they probably don't. So it's very context specific in terms of drafting.
The other thing to keep in mind is that you have to be really clear about what types of liability you want to exclude. If it doesn't exclude negligence using words to that effect, the court will read it down to just exclude liability in contract, for example.
That said, in our practice, and Steve can talk to this as well, those limitation of liability clauses are very useful when you get to a dispute. I've got a matter at the moment with another MSP who suffered a cyber attack. It has limitation of liability clauses in its contracts, and it's facing claims from customers and PI claims.
Tim Stephinson: PI claims. And so is that from their own internal side, cyber?
Christy Mellifont: No, so the MSP suffered the attack, and then their client data was accessed. They stored it, and it was accessed by the threat actor and traded. So they're facing multiple claims from customers. They have limitation of liability clauses in their contracts, and that is forming the background to the discussions we're having with the claimants, because there is at least a risk that those clauses are enforceable.
So it can be a really useful tool when we get to a dispute, because there's uncertainty on both sides about whether they're enforceable or not. But whether they're enforceable or not is going to be very fact specific.
Stephen Morrissey: Yeah, I think that's right. The short message is it's better to have them than not. You just need to bear in mind that they're not necessarily the be all and end all. As Christy said, context is key.
So that's a couple of ways that you can use contracts to manage risk. Another way, of course, is insurance, and particularly PI and cyber insurance. A question for Andrew and Tim. It's been said that obtaining a combined PI and cyber insurance policy can be expensive. But what are the benefits for IT service providers of going with a combined policy over standalone policies with separate insurers?
Tim Stephinson: I'll probably start with that, with a little bit of history as well. About five or 10 years ago, a lot of PI policies actually had cyber protections in them. It wasn't until cyber became its own class of insurance that we've seen professional indemnity eroded as a cover for technology providers. So the protections they might have had 10 years ago, when they did that original MSA, aren't what they have now from insurance.
We've seen this with standalone PI policies: as there's more and more cyber risk, more and more of it is being pushed into the cyber policies. Many other insurance classes as well, D&O and others, are now carving out cyber and pushing it into those cyber policies.
But when it comes to the exposures that technology providers have, many are now linked to both PI and cyber insurance. The solution for that is to have a combined PI and cyber policy, or even in some cases cyber primary with a PI policy bolted onto it. We call that a combined IT liability policy.
Take the example Christy was talking about before. Those exposures are better served when they're covered by one policy, because then you'll typically have one insurer, one case manager and one strategy for how best to restore the MSP's or tech vendor's environment and respond to the claims from the third parties.
We've actually seen some claims go through where there are separate PI and cyber policies, and the two insurers aren't always aligned. Especially with PI claims, we had one client who totally lost control of the PI claim, because in their view, once the insurers took it over, they ended up settling, and it wasn't the strategy they would have liked to pursue. We felt that with the combined nature, you get to cover those risks in a more holistic way. Andy?
Andrew Bremner: The history lesson, thank you. That takes me back. And you're absolutely right. It wasn't that long ago that DUAL used to bolt cyber insurance onto their PI policy for $200. $200, there you go. And then along the way the insurers got more and more burnt by cyber-related claims and did the carve-out.
Just to reinforce Tim's point, it's to avoid that finger pointing, where there's an exclusion of cyber in the PI policy and an exclusion of PI in the cyber policy. If you have a claim that slots in the middle, there's a bit of dispute about where it lands. A combined policy just removes that. We know that you're paying about 20% more. It really depends, but as a rule of thumb it's around that for a combined policy.
We are seeing, for example, and we were just talking about it earlier, Emergence, as a cyber specialist, including IT liability and launching that product, to have a combined IT liability and cyber, because they know this is probably where the market needs to head.
Stephen Morrissey: Yeah, I think that's right. Just echoing what you've both said, particularly with things like mitigation itself. If you've got two insurers and you're dealing with a cyber incident, you've always hopefully got at least one eye on mitigating third party claims arising from that incident.
That's a dispute we see quite often: are the costs being incurred properly mitigation costs that should go under the PI policy, or are they just ordinary incident response costs that should go under the cyber policy? If you've got two different insurers, they're probably going to have two different views on those things, so it becomes a bit of a mess.
All right, Christy, I might turn to you again and talk a little bit about disputes. We've talked a bit already about disputes generally. Obviously disputes are a fact of life. They're going to arise for technology providers at some point, hopefully not too often. But what are some means that parties to a tech contract can either avoid disputes arising in the first place, or resolve them in an efficient, fair, cost-effective way when they do arise?
Christy Mellifont: Preventing disputes: you can do that in the contract by having good governance processes, which means people have visibility when issues are arising, or with effective contract management regimes. Using the example I gave before about scope creep and change requests, if you've got contractual mechanisms for change requests and variations to the scope that are really clear, that can help avoid disputes.
In terms of resolving disputes, dispute resolution clauses are important. A good one should have a mechanism for escalating the dispute up to the representatives and executives in the respective companies, and if that doesn't resolve it, some kind of alternative dispute resolution. We think mediation is a really good way. It brings in an objective third party, which can sometimes be really helpful.
We sometimes see arbitration clauses. In my experience, arbitration is really expensive, and it's a quasi-judicial process. Sometimes you end up spending as much on arbitration as you would on starting proceedings. So we find mediation really effective. Generally you need to get the right mediator, though: someone who knows a little bit about technology.
Stephen Morrissey: That is an important point.
Christy Mellifont: Yeah, because otherwise they're not going to understand the issues if they're technical ones.
Stephen Morrissey: And do we think having IT liability insurance can help with disputes as well? Does that make a dispute easier for a technology provider to handle?
Andrew Bremner: I would argue absolutely. IT liability is professional indemnity and public and products liability combined, specifically built for tech and IT companies. Most of the claims for MSPs fall in the professional indemnity, PI, bucket. And most of the costs, something in the order of 70% to 80% of the cost of any claim, is legal. So it helps people negotiate and weave their way through a claim.
Tim Stephinson: In the nature of those combined policies as well, you also have some insurers that will step in early, without triggering your policy, to actually help you decide who's at fault, or whether it's your customer's issue or yours. So don't be afraid to bring the insurer into the conversation. I think sometimes everybody thinks, "I don't want to tell my insurer, because then it's going to become a big problem." But bringing them into the conversation can also be an advantage.
Stephen Morrissey: Great. And Nick, coming back to you. If we've had a dispute, or contracts just have to come to an end at some point, what can parties do to consider and cover off a proper exit management strategy?
Nick Martin: Yeah, good points. Not necessarily as a result of a dispute or a termination: all good things come to an end anyway. Deals are a lot shorter, I think, than they probably were five or 10 years ago. And in the excitement of the honeymoon phase, the sexy new deal or engagement, people don't tend to turn their mind to what happens at the end. So again, it's the technology agreement or the MSA that has to do that heavy lifting.
The more dependent a customer is on its vendor, MSP or supplier, or the more complex an engagement is, the more important that exit phase will be. The key question is really: do we need a transition-out period, where the incumbent provides some services over and above BAU to help you move something back in house or maybe to a new supplier? So always ask that question. And then from the supplier's perspective: how am I going to get paid for that? That's additional work and I'm not doing it for free. So is that just time and materials, or is there a separate charging or scoping process for that transition-out work?
Tim Stephinson: Do you ever see people calling that out in the MSA, so it's upfront to say this is what transition looks like?
Nick Martin: Absolutely. Those are the good contracts and the good agreements, because it shows people have thought about that at the outset. They know this is how it's going to end. It'll be smooth and orderly, rather than people scrambling around and fighting about "No, you should do that" and "No, we need to be paid."
You want to incentivise your provider to provide a good service on the way out, and usually the way to do that is to agree to pay for it. There are also other issues to think about, such as return of customer data. How are you going to get your data back if you're the customer? In what format? Do you have to pay for that? What if you don't need it back? Well, the supplier obviously needs to delete it within the same timeframe.
Then there are other issues around surviving clauses: which parts of the contract should go on living after the contract comes to an end. It's usually things like the liability regime, confidentiality provisions and things like that. So there's a lot to think about, and we find the exit phase doesn't get the attention it deserves. But please turn your mind to it upfront.
Andrew Bremner: I can see it's kind of unsexy, but it's so valuable, and you're absolutely right. There's always going to be an end.
Stephen Morrissey: The divorce papers. I suppose it's all well and good to think about these sorts of things and seek to include these sorts of terms in your contracts. But often, if not always, there's some negotiation back and forth between the parties about the terms of technology contracts, or any contracts really. Do you have any tips on approaching those negotiations, to make sure you don't do anything that causes the deal to die?
Nick Martin: Look, I guess it really is unavoidable. Customers don't typically contract on the supplier's paper with zero amendments, and the opposite is true. Everyone's going to want changes. And as we said earlier, the objective isn't to absolutely nail someone down to a deal they're going to hate for the rest of its life. Apportion that risk fairly and reasonably, so both parties have, to use the cliche, a win-win situation.
In terms of how you approach it, firstly, make sure it's factored into the timeline of the process as a whole. It's not going to happen in a day or two, or even a week or two, for complex engagements. You're often looking at weeks and months. Not to scare anyone, but that's just the fact of life: documents have to go back and forth, meetings have to happen, and escalations within organisations need to happen. So it can be a time-consuming process. Focus on the key areas and the key risks. Don't just try and score points for the sake of it.
Tim Stephinson: A lot of our clients, being managed service providers, take a lot of vendors' products and resell them through to their customers. And a lot of the vendors, when I speak to them, say, "Well, we limit our liability to the MSP." Then the MSP takes those products and sells them into their customers. Are there any tips you can think of for making sure the MSAs are back to back, from vendors through MSPs to their customers, or things MSPs can do to protect themselves? Because sometimes there's a big fish on either side of a small service provider.
Nick Martin: It's a hard one. You can be the meat in the sandwich in that scenario. The big global vendors very often won't budge. They've got a policy or a guideline on their liability positions, and they'll only move from that for massive deals.
And the customers on the other side, again, have their own guidelines on what they will and won't agree to. Very often it will come down to appetite for the deal. If the MSP really wants to do that piece of business, it may need to take a bit of risk in the middle.
Bear in mind that the liability regime is typically the worst case scenario, because you're looking at proceedings, or being sued, essentially. Before it gets to that, there are plenty of other levers you can pull to make sure a good service is delivered, so that the liability regime and clauses only ever exist as a hypothetical. So even though it can be scary, sometimes it's a risk you have to live with if you're caught in the middle.
Tim Stephinson: One of the basic ones we highlight is that the claim is going to follow the line of contract. So if there's a supply chain issue with, insert large vendor here, that supply chain exposure is typically going to flow through the MSP. That's where the combined IT liability policy really comes into play.
I tell a lot of our customers: if your PI proposal doesn't ask about your vendors, it doesn't typically include them. So that's a little takeaway: make sure that combined IT liability policy is there to group them all together, so if there's a supply chain issue, it's included if you were to make a claim on it.
Andrew Bremner: And that exposure for MSPs, the reliance on vendors, is only going one way. It's been trending up for many years, to almost total reliance. Often the MSP is a major reseller of the vendor's kit and services, and that comes with a lot of exposure. If the vendor gets it wrong, it flows through the MSP to the customer. It's a major exposure for the MSP, and perhaps there are opportunities within the MSA to protect against that.
Nick Martin: So look, one of the tips, Steve, while we're on the topic of negotiations. Something I think people will probably come across at one time or another is the parties agreeing to agree something later on. So, "We'll agree that bit of scope as soon as reasonably practicable after the commencement date."
There are a few reasons why that's a bad idea. It might cause the whole contract to be unenforceable: if the term is so fundamental, the whole thing falls over for uncertainty. There's the loss of bargaining power point: people might not have the power they could wield pre-signature once the ink has dried. And more practically, people just move on to the next thing, so the appetite might not be there to revisit it. So in terms of negotiations, try not to agree to agree, for those reasons.
Christy Mellifont: That's a really good tip, actually. Coming from a construction background, I've seen that happen time and time again, and you get left holding the baby.
Stephen Morrissey: One of the things that I understand often takes a lot of time and effort to resolve during negotiations is clauses to do with compliance with laws. Why does that cause so much angst for IT service providers? And do you have any tips for finding an easy path through that issue?
Nick Martin: Yeah, it is often a big issue. Not usually when each party just has to comply with applicable laws. That's not a big deal, that's not controversial. It's more when the customer seeks an obligation on the supplier that the supplier will comply with what you'd call customer laws: laws that apply to the customer's business and existence, but not the supplier's.
And the supplier says, "Well, look, how would I know what legal regime you operate in? What laws are applicable to you but not me? I can't agree to not place you in breach of those laws. I don't know what they are." That's really the fly in the ointment a lot of the time.
In terms of how to get through that, there's really only one way, and that's to ask the customer to document clear obligations which, if the supplier meets them, tick those boxes for the customer. It's too vague to say, "Okay, I'll comply with customer laws." Instead: "I can do X, Y and Z to make sure that you comply with your laws, or at least don't breach them."
A good example of that is regulated entities. They have significant requirements under prudential standards, something like CPS 231 and CPS 234. Very often, if you're acting for customers, there are a number of areas you'll need to include in the technology agreement so that you can comply, and so you can make sure the supplier helps out in meeting those prudential standards. So again, it's really specificity, rather than that vague obligation to comply with someone else's laws.
Stephen Morrissey: Makes sense. Switching back to cyber insurance for a moment, Tim and Andrew. I was wondering whether all cyber insurance policies are created equal, in your view? And if not, what should tech professionals, or anyone, be watching out for when considering obtaining cyber insurance?
Andrew Bremner: No. I'll jump in first. So the short answer, and another history lesson coming on: cyber is a very new insurance. It's only about 15 years old, whereas most other insurances that we take for granted, property and liability, are around 330 years old. So they have lots of precedent and lots of experience. Cyber is a very new insurance, and there's a huge amount of variation in the coverage and the quality of the coverage. It does need help and navigation to get through it.
What we do say is that a good cyber insurance policy is primarily a first party policy. What we mean by that is it's protecting you, your business, in the first instance. So we like strong first party cover, third party cover in terms of the defence component, and also social engineering crime. A good policy has those elements. However, it's really going to be specific to what your needs are. It's never one size fits all. It needs a discussion and an understanding of what the risk elements are.
Tim Stephinson: I always like to ask our customers: what's your expectation of your cyber insurance policy? If everything blows up, what do you actually want it to do? Businesses that hold equipment in data centres, for example, absolutely need coverage for hardware. They need to be able to replace that hardware on the spot, because if it's ransomware and it's locked up, they need to recover somewhere. But if you haven't been through that DR strategy piece, then you don't really understand what you actually want the policy to do.
We see a lot of large companies requiring MSPs and providers to hold cyber insurance as a bit of a tick-the-box, so you meet their buying requirements. We see New South Wales Government wanting $20 million of cyber cover for their ICT policies, and other requirements like that. But you really want to ask: what do you actually want it to do for you as a business? For some it's social engineering, for some it's incident response. Business interruption is probably one of the biggest ones. It's about understanding what's going to happen when you pick up the phone, call the insurer and say, "Now we need to trigger the policy." What's your expectation?
Andrew Bremner: Probably one of the biggest things we see the value in, in terms of a cyber policy, is the 24/7 incident response that you guys know so well. That's really what you're paying for. We've seen examples with our own clients having those bad experiences, having the incident and almost losing their businesses. And it's a great one for you guys: you led the charge, it was legal led, and it delivered an outcome for our client, who had strong tech capability but was unable to get themselves out of the pickle. The Avengers came, you guys led the charge, and you saved the business within four days, got it resolved, and probably negated a whole bunch of PI claims.
Tim Stephinson: There's a bunch of myths around insurance in general as well: will it actually cover me, will it actually pay? In our experience, it absolutely does cover you. You've just got to make sure, as it's a contract of mutual honesty, that you are honest about the risk you're trying to cover, and the insurer will then cover those exposures.
Stephen Morrissey: Just touching on something you mentioned then, Andrew: the flip side of all of this is if an MSP doesn't have cyber insurance. I'm actually aware of one case where an MSP was hosting data for about 100 clients. It had PI but didn't have cyber insurance. There was a massive ransomware event, and that business was not trading within two weeks. An absolutely catastrophic impact, which could have been avoided if there had been a cyber insurance policy.
Andrew Bremner: And it's sad. You see the owner of the business, and they're going, "This business that I've built up over the last 10 years could be gone, and I could lose my house as a result." It becomes very personal with these things.
Stephen Morrissey: And again, touching on something you mentioned before: does the cyber insurance protect the technology provider itself and its customers, or do their customers need their own cyber insurance as well?
Andrew Bremner: The latter. They certainly need their own cyber insurance. Cyber insurance is primarily a first party policy that protects the holder of that policy. Often it will have a third party element that helps them defend claims against them from third parties. But often those third party claims slip between professional indemnity and cyber.
Tim Stephinson: Just on that point, Andy, it was raised by one of our larger customers that they didn't encourage their customers to hold insurance, because the lawyers or the cyber insurer would come after them. I think it's something you guys have knowledge on as far as recoveries go. Do you see a lot of recoveries, where a policy is triggered and the insurer then comes after the small business that provided the services, in a cyber claim?
Stephen Morrissey: Probably not as common as you'd think. Not to say it doesn't happen, if I'm being honest, but I think that concern is probably being a bit overblown in the market at the moment.
Andrew Bremner: And just to add a bit of a myth buster here. We often see MSPs saying to us that they see the incident response component in the industry as a competitor. And we say it's not competing, and it would be great to get your view, but it is so much more, and so much greater, than what the MSP can deliver.
Tim Stephinson: Or what a single vendor can deliver. A single vendor in a security stack trying to manage an incident response hasn't got the legal looping to consider the regulatory and other requirements that are in the best interest of their customers.
Stephen Morrissey: Yeah. I don't want to turn this into an ad for our cyber team, but they really do handle the situation from top to bottom. They get the right vendors to do the work, do the forensic work, and the right vendors if there are ransom negotiations.
Andrew Bremner: By the way, we are fans.
Stephen Morrissey: They have everyone on a call within half an hour of getting the call. They've got the right vendors in place and they can respond really quickly. From an MSP's perspective, I imagine the cost to the business of responding to something like that without those vendors at your fingertips can be quite different. And then of course you also get the advice on the privacy piece, once data has been accessed.
Andrew Bremner: We are seeing that it needs to be legal led. There are too many legal obstacles and too much navigation required. It needs to be legal led. Everyone should be tuning into the Privacy Act webinar on Thursday as well. That's a piece everyone needs to understand. Sorry, just a thought bubble through the discussion: there's actually not enough promotion of the benefits of incident response. We talk about it a lot, but the turnaround stories are incredible, and there's not enough of that.
Stephen Morrissey: Okay, a few minutes to go. I might turn back to you, Nick, for a couple more tech contract tips before we go. The first one is in relation to governance and contract management, and why that is so important for ensuring a good relationship between the parties. Firstly, would you agree with that proposition, and what can go wrong in the absence of good governance?
Nick Martin: Yeah, I definitely agree, and I think Christy touched on it before. Contract management and good governance is key to optimising the value of the investment the customer has made. That's from their point of view. From the supplier's point of view, it's absolutely crucial to avoid disputes, delays and cost overruns. It's all about getting early visibility of something coming down the pipe that's not quite going according to plan.
The more mechanisms, tools and forums the contract puts in place to manage that on a day-to-day basis, the better, because you'll have that early visibility and the means to resolve something or get it back on track before it's truly pear-shaped. So it's really about avoiding problems. Make sure the contract has really clear and workable governance processes and a contract management regime to address things like scope creep and cost issues.
Stephen Morrissey: All right, last one, noting the time. This might be a fairly self-interested question, to be honest. Noting the wider legal environment that technology agreements operate within, how important do you think it is to keep up with developments in case law and legislation? And do you have any examples of how not doing that has gone wrong?
Nick Martin: Look, this is kind of one for the lawyers, if there are any on the call. There was the classic one from a few years ago on the definition of consequential loss, which we talked about earlier in the context of liability exclusions. Without going into too much detail, a case came along out of Victoria and completely upended the accepted wisdom, which stretched back to an 1800-something case out of England. Suddenly an exclusion of consequential loss was much broader than it was previously.
That was probably pretty good news for suppliers and vendors, but obviously in response, customers were trying to wind the position back to the earlier case law through their drafting. So that was a really good example of where a case could come along and really disrupt the technology landscape.
In terms of legislation, as we just mentioned a minute ago, the Privacy Act is changing before our eyes, finally, after five years of talking about it. We've just had the first tranche of reforms. The bill has passed, but I don't think it has Royal Assent yet, though that's obviously around the corner. Then we're looking at much bigger changes potentially next year, to cover off the rest of the proposed reforms.
That will have a massive impact on the privacy and security clauses in technology agreements, because customers will need to revisit them to make sure they can comply with their regulatory obligations: what does my supplier need to do to help me with that? So those are just two examples, a case and a legislative change, that demonstrate that, as I said, these agreements don't live in a vacuum. You've got to keep across it.
Stephen Morrissey: Great. Okay. Any final thoughts, Nick?
Nick Martin: Really just that we didn't even get to cover all the things we could have talked about today. But I think it's fairly apparent that the technology agreement, whether it's an MSA or something similar, needs to do a lot of heavy lifting. It mitigates a lot of risk and really protects providers of technology in particular.
So don't let them gather dust in a drawer. Review them regularly and make sure they're fit for purpose. All things being equal, it should do what it's meant to do, which is apportion risk and be the manual for a relationship or an engagement.
Stephen Morrissey: Tim, Andrew, Christy, anything?
Andrew Bremner: I think it's a real opportunity to leverage the specialists. Leverage legal people with the knowledge to help navigate you through, and leverage the insurance specialists. Technology and the related insurance is becoming so niche and specialist now. You need someone to help you, and we are certainly very happy to assist. The other thing we can offer is our insurance health check at no charge. The worst case is that we confirm you've got the best program to meet your needs. And thank you very much to everyone here.
Tim Stephinson: I think it's really important to reach out to the specialists, especially Wotton + Kearney, and to go early as well. Don't come to somebody late. If you are doing a new program or a new offering to customers, discuss the legal requirements early and build them into the offering.
Stephen Morrissey: Couldn't agree more. Okay, well, that brings us to the end of the session. Thanks, everyone, for making the time. We'll send out a summary pack in the next few days, which will contain a recording of this session, a few slides, key takeaways, and also some answers to questions. I've seen a couple of questions come through, and apologies we didn't have time to get to them, but we will answer those as part of the summary pack.
If anyone has any other feedback or questions in relation to the webinar, please feel free to send them through and we'll get back to you. Otherwise, thank you, Tim. Thank you, Andrew. Thank you, Christy. Thank you, Nick, for today's session. And thank you to everyone for joining us. See you at the next one.
.png)
