Software Vendor Governance: SLA, IP Ownership, and Exit Plans
The most expensive risk in a software project usually isn't that the vendor does bad work: it's the company discovering, two years later, that it doesn't own the code, has no access to the infrastructure running its operation, and no one defined what happens if the relationship ends. That's not fixed with good technical execution; it's fixed — or not — in the contract.
Choosing the right vendor is the first half of the problem, and we cover it in how to choose a software development agency. This guide is the second half: what needs to be in writing so the company keeps control of an asset it will run for years.
1. Intellectual property: who owns what
It's the clause most companies sign without reading, and the one that costs the most later. In custom development, the rule that protects the client is full assignment of economic rights over the code built specifically for the project, effective upon payment, and in writing.
There are three layers worth distinguishing, because not all of them transfer — nor should they:
| Layer | What it is | Who should own it |
|---|---|---|
| Project code | What was written for your business | The client, full assignment |
| Vendor's proprietary components | Reusable internal libraries | The vendor, with a perpetual, irrevocable license for the client |
| Third-party software | Open-source libraries, services | Their respective rights holders, under their license |
Two concrete red flags: a contract that only grants a license to use the project code instead of assigning it, and one that stays silent on the vendor's proprietary components. In the first case, you can't hire someone else to modify it; in the second, the day you switch vendors you discover a core piece of the system doesn't come with you.
Also ask for the list of third-party dependencies with their license. A strong copyleft library embedded in the core of a product you plan to commercialize is a problem that's cheap to catch before signing and expensive after.
2. Access to infrastructure and repositories
Owning the code is worthless if you have nowhere to take it from. The practical rule is simple: root accounts for everything that runs your operation must be in your company's name, with the vendor invited as a collaborator — never the other way around.
This applies to the cloud provider, the domain registrar, the code repository, app store accounts, the payment gateway, and email and messaging services. It's the difference between switching vendors in a week versus being locked out for months.
Also require that the repository receive code continuously from day one, not as a final delivery. A repository your company has access to throughout the project is also the best verification that work is actually progressing.
3. Service levels that can be measured
An SLA is only useful when it defines observable events and consequences. The four parameters it shouldn't be missing:
- Committed monthly uptime. 99.9% allows about 43 minutes of downtime a month; 99.5% allows about 3.6 hours. The cost difference between the two levels is real, so it's worth choosing the one that matches the system's criticality rather than the highest one by reflex.
- Response time and resolution time by severity. Kept separate: responding isn't the same as resolving. And severity should be defined by business impact, not by the vendor's technical judgment.
- Maintenance windows. When planned downtime can happen and how much advance notice is required.
- Consequence of non-compliance. Normally a credit against the monthly fee. An SLA with no consequence is just a statement of intent.
The investment ranges tied to ongoing support are covered in annual software maintenance cost: between 10% and 35% of the initial investment, depending on the system's criticality.
4. Personal data: the vendor is a data processor
If the system processes personal data — customers, employees, users — your company is the data controller and the vendor is the processor. That relationship requires a written agreement, and liability toward the data subject and the authority cannot be delegated: it remains yours even if the incident happens on the vendor's side.
The agreement should cover at least the authorized purposes, a prohibition on using the data for the vendor's own purposes, security measures, the subcontracting regime, an obligation to report incidents within a defined timeframe, and certified return or deletion of the data when the relationship ends. In Colombia the applicable framework is Ley 1581 de 2012 (Colombia's data protection law) and its implementing decrees, covered in detail in what your software must comply with under Ley 1581.
One point that's frequently overlooked: production data used in test environments. If the vendor works with real copies of your database, that's personal data processing and needs to be regulated — or better, replaced with anonymized data.
5. The exit plan is written at the start
No vendor relationship lasts forever, and the right time to define the exit is when both parties still have an incentive to be reasonable: before signing. A useful exit plan specifies:
- What gets delivered: complete source code with its history, architecture documentation, credentials, deployment scripts, and data in a standard, documented format.
- In how much time: a concrete deadline from notification, not "within a reasonable time."
- With what support: a paid transition period with defined availability to answer the incoming team's questions.
- And in what state: the system must be deployable by a competent third party based solely on what was delivered. It's the clause that prevents a delivery that's formally complete but practically unusable.
A source code escrow deposit is also worth considering when the system is critical and the vendor is small: a third party holds a copy that gets released if the vendor disappears or breaches the contract.
Frequently asked questions
Who owns the code in a custom development project? It depends on what the contract says, not on who paid. By default, economic rights originate with whoever wrote the code, so the assignment to the client must be written explicitly. If the contract only grants a license to use, the company can't hire a third party to modify the system.
What uptime level should I require in an SLA? Whatever matches the real impact of an outage. For internal back-office systems, 99.5% is usually enough; for customer-facing transactional platforms, 99.9%. Demanding 99.99% for a system that doesn't need it just drives up architecture cost with no benefit.
Can I switch vendors without rebuilding the system? Yes, if from the start you have rights assignment, repository access with the full history, infrastructure root accounts in your name, and deployment documentation. Without those four elements, switching vendors looks a lot like starting a new project.
Can the vendor reuse what they built for me with other clients? It should be spelled out explicitly. The reasonable arrangement is that they can reuse their generic components and general know-how, but not your specific business logic or anything that reveals confidential information about your operation.
What happens to liability if there's a data breach on the vendor's side? Toward the data subject and the authority, primary liability remains with your company as the data controller. The contract governs how responsibility is allocated internally between the parties, but it doesn't shift the legal obligation outward. That's why the processing agreement and verifiable security measures matter so much.
A clear contract protects both parties
None of this is a defense against a bad vendor: it's the structure that lets a good relationship last for years without turning the company into a hostage of its own system. A serious vendor won't push back on any of these five points, because they protect the vendor too.
At BigBoc we work with companies across Colombia and Latin America in React, Next.js, Node.js, and artificial intelligence, with full rights assignment over project code, infrastructure in the client's name, and deployment documentation from day one.
About to sign with a vendor and want to review these points first? Request your free quote at bigboc.com/cotizacion and get a proposal with scope, timeline, and costs in under 24 hours. Prefer to discuss your case first? Reach out through our contact form.