Custom Software Development Legal & Contract Checklist (US): IP, Indemnity, SLAs, Termination

Arbisoft Editorial TeamPosted on February 21, 2026

17-18 Min Read Time

Why Contract Clarity Matters in Custom Software Projects

Custom software projects fail in predictable ways because the contract makes the hard parts ambiguous.

Four clause families do most of the damage when they are vague or one sided:
 

• IP terms decide whether you can use, modify, and maintain what you paid for.
• Indemnity and limitation of liability (LoL) decide who pays when something goes wrong.
• Service levels (SLAs) decide whether support and uptime promises are measurable and enforceable.
• Termination and transition decide whether you can exit without operational downtime or lock in.
   

This is not legal advice. Use it to prepare a clean issue list and “what we need” artifact list for counsel and for vendor redlines.

What this checklist is and who should use it

This is a procurement grade checklist for US focused custom software development deals, especially when you are buying a meaningful system, a platform component, or anything that will be business critical.

It is meant for:
 

• Procurement and vendor management
• Legal or contracting counsel (in house or outside)
• Engineering leadership who will own maintenance
• Security and privacy stakeholders where personal data is in scope
   

Use it to align internally first, then negotiate. The fastest way to lose leverage is to “discover” requirements after the vendor has priced and scheduled the work.

How to use this checklist in procurement 

The contract checklist works best as a repeatable process instead of a one time document review.

A simple flow:
 

1. Collect the full document set so you are not negotiating blind.
2. Review in the right order (MSA first, then SOW and schedules).
3. Pre align internal positions (must have, fallback, escalation).
4. Run the checklist and log gaps as negotiable issues, not “nice to haves.”
5. Close gaps with either contract language or specific exhibits and artifacts.

Collect the right documents first 

For a baseline custom software engagement, request these before detailed review so you are not negotiating blind:
 

• Master Services Agreement (MSA) for core risk allocation (IP, indemnity, LoL, confidentiality, term and termination, governing law).
• Statement of Work (SOW) for scope, deliverables, milestones, acceptance criteria, fees.
• SLA exhibit or support policy for uptime and support response and resolution commitments, plus credits or remedies.
• Security or information security exhibit for baseline controls, audit rights, and incident notification commitments.
• Data Processing Addendum (DPA) if personal data is involved (roles, subprocessors, cross border transfer posture).
• Open source software (OSS) policy or at minimum vendor representations on third party and open source usage.
• Software bill of materials (SBOM) for significant systems, or at least a commitment to provide license notices where applicable.
• Certificates of insurance (COIs) showing relevant coverage (commonly E&O and cyber liability, plus general liability where appropriate).
  
   

If the vendor cannot provide a referenced exhibit, treat it as a stop sign. “We will send it later” is how contracts end up with obligations that are not actually operationalized.

Define your internal positions

Before you redline anything, decide what matters most for your risk profile and operating model.

A practical way to do this is a lightweight negotiation matrix:
 

• Must have: deal breaker without leadership approval.
• Fallback: acceptable with specific guardrails.
• Escalate: requires legal plus business owner sign off.
   

Tie positions to risk tiers. For example, a vendor building a public facing, revenue critical system should not be treated like a low risk internal tool.

If you need deeper structure on how the MSA and SOW should be organized, how governance should run, and how change control should be documented, use the contracts and governance guide.

If you need a structured way to compare proposals and force vendors to disclose assumptions and exclusions, use the RFP template.

Legal & contract checklist for custom software development

How to read each item of the checklist

Each checklist item is formatted as:
 

• Question: the clause level decision you need to resolve.
• Why it matters: the operational or financial failure mode it prevents.
• What to discuss with counsel: the legal validation or drafting nuance.
• What to request: the specific exhibit, artifact, or evidence that makes the clause real.

1) Intellectual Property (IP) and deliverables ownership

If you only do one thing in this checklist, do this: make the deliverables list explicit and make ownership and license grants unambiguous.

Deliverables list: what you should receive at handoff

Question: Does the SOW define deliverables beyond “working software”?

Why it matters: If the only deliverable is a running system, you can end up unable to build, deploy, or maintain it without the vendor.

What to discuss with counsel:
 

• Whether deliverables must be a condition of acceptance and final payment.
• How to handle partial delivery and staged acceptance.
   

What to request (examples to tailor):
 

• Source code in your repos (or a clearly defined repo handoff)
• Build scripts and deployment pipelines
• Infrastructure as Code (IaC) for environments where applicable
• Architecture diagrams and design files
• Test suites and test data handling approach
• Runbooks, operational docs, and support procedures
• Admin credentials and access documentation
• Dependency and configuration documentation

Ownership vs license: custom work, pre existing components, and reusable libraries

Question: Who owns the work product, and what does the vendor retain?

Why it matters: Many vendors use a mix of custom work, pre existing tools, and reusable libraries. If the contract does not distinguish them, you can pay for software you cannot freely use.

What to discuss with counsel:
 

• Whether the project outputs are assigned to you (foreground IP) or licensed.
• Whether the vendor’s background IP is disclosed and licensed for your use.
• Whether any “work made for hire” language is appropriate for your situation and enforceable for the deliverables.
   

What to request:
 

• A schedule that lists vendor background IP and any third party components.
• A clear license grant for vendor retained components that are required to use the deliverables.
• A statement of your rights to modify, maintain, and create derivative works of the deliverables you receive.

Escrow, access, and continuity: repo access, credentials, and handoff obligations

Question: Can you keep operating if the vendor relationship changes?

Why it matters: Lock in often happens through access. If you do not have admin rights, credentials, or repo access, exit becomes slow and risky.

What to discuss with counsel:
 

• Whether the contract should require ongoing access during the engagement.
• Whether any step in rights or similar continuity mechanisms should be flagged for higher risk systems.
   

What to request:
 

• Repo access model, including admin rights and offboarding steps.
• Credential and secrets handoff process (with secure handling).
• Transition assistance obligations tied to termination events.

Open source and third party components: policy, SBOM, and compliance

Question: How are open source and third party components selected, tracked, and disclosed?

Why it matters: Open source components can create licensing obligations and supply chain risk. If the vendor cannot explain governance, you inherit risk without visibility.

What to discuss with counsel:
 

• Representations and warranties related to third party and open source use.
• Whether you need approval rights for certain licenses or components.
• Whether SBOM delivery should be required for critical systems.
   

What to request:
 

• Vendor OSS policy (or a written description of their controls).
• SBOM for significant systems or a commitment to provide one on request.
• License notices and disclosure process.

2) Indemnity and liability (risk allocation)

Indemnity and LoL decide who pays when the contract fails in the real world.

The practical goal is not “maximum vendor liability.” The goal is alignment: the party best positioned to prevent a risk should bear meaningful responsibility for it, and the contract should be backed by insurance where possible.

IP infringement indemnity: scope, control of defense, and exclusions

Question: Does the vendor provide a clear IP infringement indemnity for what they deliver?

Why it matters: If a third party claims infringement, defense costs can be material even if you ultimately win. A thin indemnity shifts the cost and distraction to you.

What to discuss with counsel:
 

• Scope: what is covered (deliverables, third party components, vendor provided tools).
• Control of defense: who appoints counsel, how settlement decisions are made.
• Exclusions: when indemnity does not apply, and whether those exclusions are too broad.
   

What to request:
 

• A clear statement of defense and indemnification obligations.
• Remedy language such as substitution, modification, or replacement if infringement is alleged.
• Settlement consent protections if a settlement would restrict your use.

Security and data related indemnities: when they appear and how they are framed

Question: If sensitive data is involved, what happens if a security incident triggers third party claims?

Why it matters: Many contracts point to security exhibits and DPAs but do not clearly map liability and indemnity to those obligations.

What to discuss with counsel:
 

• How security obligations in an exhibit interact with LoL carve outs.
• Whether privacy or data related claims should be addressed through indemnity, specific remedies, or a separate risk allocation mechanism.

What to request:
 

• The security exhibit and DPA before you finalize the MSA.
• Clear incident notification commitments and cooperation obligations.
• Confirmation that insurance coverage aligns with the obligations being negotiated.

Limitation of liability (LoL): caps, super caps, and carve outs

Question: What is the liability cap, what is excluded, and what is carved out?

Why it matters: A vendor can promise a lot in indemnities and warranties, then cap liability so low that the promise is mostly symbolic.

What to discuss with counsel:
 

• The cap basis (fees paid, annual fees, specific amounts).
• Whether there are carve outs (for example, for confidentiality, IP infringement, or certain security events).
• Whether consequential damages exclusions are appropriate given your risk profile.

What to request:
 

• A plain language summary from the vendor of how the cap works in common failure scenarios.
• A marked up LoL clause that clearly ties to indemnity and confidentiality language.

Insurance requirements: what to request and how to sanity check

Question: Are the vendor’s contract commitments realistically backstopped by insurance?

Why it matters: Insurance does not replace contract terms, but it can be the difference between a claim being collectible or purely theoretical.

What to discuss with counsel:
 

• Which coverage types and limits are appropriate for the engagement.
• Whether you should be named as additional insured for any policies where that makes sense.
   

What to request:
 

• Certificates of insurance covering relevant policies (commonly E&O and cyber liability, plus general liability).
• Renewal dates and any notice requirements for cancellation or changes.
• Confirmation that subcontractors carry similar coverage where they are doing meaningful work.

3) Service Levels (SLAs) and support terms

If you expect ongoing operation, you need measurable service commitments. Marketing statements about uptime do not count unless they are contractually defined and tied to remedies.

Define what the SLA covers (production only vs all environments)

Question: What systems and environments are actually covered by the SLA?

Why it matters: Vendors often limit SLAs to production only, exclude beta features, or exclude issues tied to third party services. That may be fine, but it must be explicit.

What to discuss with counsel:
 

• Whether the SLA is a schedule to the MSA, part of a support agreement, or embedded in the SOW.
• How exclusions and maintenance windows are defined and measured.
   

What to request:
 

• The SLA exhibit or support policy in writing.
• A scope statement that lists included services and excluded components.

Metrics that matter: uptime, response time, resolution time, severity levels

Question: Are the service level indicators measurable and tied to severity definitions that match your business impact?

Why it matters: The most common failure mode is a vague severity definition that allows serious issues to be treated as low priority.

What to discuss with counsel:
 

• Whether the contract defines response time versus resolution time.
• How severity is determined and whether you have a role in escalation.
   

What to request:
 

• A severity matrix and definitions.
• Measurement method for uptime and how outages are counted.
   

Below is an example structure you can use as a sanity check. Tailor the times and definitions to your operating model and risk profile.

Credits, remedies, and chronic failure provisions

Question: What happens if the vendor misses commitments repeatedly?

Why it matters: Service credits can be useful, but only if they are meaningful and if chronic failure triggers stronger remedies.

What to discuss with counsel:
 

• Whether service credits are capped and how they are applied.
• Whether repeated failures trigger termination rights or other remedies.
• Whether any step in rights concepts should be raised for critical systems.
   

What to request:
 

• A clear credit schedule with caps and eligibility conditions.
• A chronic failure clause (for example, repeated misses within a defined window).
• A link between chronic failure and termination for cause if appropriate.
   

Dependencies and shared responsibility (cloud providers, your team, third parties)

Question: Does the contract define shared responsibility so the vendor cannot default to “not our fault”?

Why it matters: Many incidents involve boundaries: cloud providers, third party APIs, your internal operations. You need clarity on who coordinates, who communicates, and who owns mitigation.

What to discuss with counsel:
 

• How dependency failures are treated under SLA measurement.
• Cooperation obligations for incident response and root cause analysis.
   

What to request:
 

• A dependency list and responsibility assignment (often a simple RACI style statement).
• Incident coordination commitments, including communications and post incident reviews.

4) Term, renewal, and termination (including transition assistance)

Exit terms are operational planning.

Term and renewal: auto renew traps and renewal notice windows

Question: Does the agreement auto renew, and how much notice is required to avoid renewal?

Why it matters: Auto renew clauses with long notice windows can lock you into an additional term even when performance is poor.

What to discuss with counsel:
 

• Whether renewal should be explicit rather than automatic.
• What notice window is procurement friendly for your organization.
   

What to request:
 

• Clear renewal language and notice requirements.
• A contract calendar reminder plan internally.

Termination for convenience vs cause: triggers, cure periods, and disputes

Question: Can you terminate for convenience, and what does termination for cause actually require?

Why it matters: Termination for cause often includes cure periods and dispute mechanics that delay exit. Termination for convenience can be expensive if fees and deliverables are not structured properly.

What to discuss with counsel:
 

• Cure periods and what constitutes a material breach.
• Payment obligations on termination and how work in progress is treated.
• Escalation and dispute processes that could delay termination.
   

What to request:
 

• A clear termination section describing triggers, notice, and cure.
• A statement of what happens to deliverables, repos, and access at termination.
• A clause requiring cooperation during transition, including reasonable access to personnel.

Transition assistance: handoff plan, timelines, and fees

Question: Is transition assistance defined, priced, and enforceable?

Why it matters: If transition assistance is vague, it becomes a new negotiation during a stressful moment.

What to discuss with counsel:
 

• Whether transition assistance is included or billed at pre agreed rates.
• Minimum timelines for support after notice of termination, especially for critical systems.

What to request:
 

• A transition plan outline with deliverables and timelines.
• A rate card or fee model for transition services.
• A commitment to cooperate with a successor vendor.

Data return and deletion: timing, formats, and attestations

Question: Can you get your data back in usable formats, and can you verify deletion?

Why it matters: Data return failures create operational downtime, compliance risk, and extended vendor dependence.

What to discuss with counsel:
 

• Required export formats and timing.
• Deletion obligations and any backup retention carve outs.
• Whether you need a deletion certificate or other attestation.
   

What to request:
 

• Data export plan with timing and formats.
• Deletion process description and proof mechanism.
• A statement on how long backups are retained and under what conditions.

5) Scope control and change requests (brief, then link out for depth)

Scope and change control is where delivery predictability is won or lost, but it is easy to go too deep and duplicate governance guidance.

At the checklist level, focus on these essentials:
 

• Does the SOW define scope, milestones, acceptance criteria, and assumptions clearly?
• Is there a written change request process that defines who can approve changes and how pricing and timelines are updated?
• Are “out of scope” items explicitly listed so you can avoid surprise change orders?
   

For a deeper walkthrough of governance mechanics, change control workflows, and how to structure the MSA and SOW to reduce ambiguity, see /contracts-governance-custom-software-development.

Common red flags and negotiation traps 

Use this as a fast disqualifier list during vendor selection and redline review.

Red flags that create lock in

• Deliverables omit source code, build scripts, IaC, or runbooks.
• Vendor will not provide repo access or admin level credentials.
• License grants are narrow, non transferable, or terminate on contract end for components you need to operate.
• Transition assistance is “best effort” with no defined artifacts, timeline, or fees.

Red flags that shift too much risk to you

• Indemnity is narrow, heavily excluded, or not tied to meaningful remedies.
• LoL cap is low relative to the project impact, especially if paired with broad exclusions.
• Security obligations are referenced but the exhibit is missing or vague.
• Insurance is refused, outdated, or does not match the obligations being negotiated.

Red flags that undermine delivery predictability

• SOW scope is high level with no acceptance criteria.
• Acceptance is undefined or defaults to automatic acceptance without meaningful review.
• Change control is informal or described as “handled collaboratively” with no written process.
• SLAs are marketing statements, not measurable commitments with defined remedies.

Conclusion: what to do next and what to bring to counsel

Treat this checklist as a pre negotiation pack. Your goal is to walk into counsel review and vendor redlines with:
 

• The full document set (MSA, SOW, SLA, security exhibit, DPA).
• A short issue list grouped by: IP, indemnity and LoL, SLAs, termination and transition.
• A “what to request” list for missing exhibits and operational artifacts.
• Your internal positions: must haves, fallbacks, escalation paths.
   

A simple meeting agenda with counsel:
 

1. Confirm deliverables and IP ownership and license structure.
2. Validate indemnity scope and LoL cap and carve outs against your risk profile.
3. Confirm SLA scope, severity definitions, and chronic failure remedies.
4. Confirm termination rights, transition assistance, and data return and deletion mechanics.