+91 98726 60544 hello@mitstech.co Mon–Sat · 09:00–18:30 IST

Subcontracting part of a project safely

IT Strategy By Mits Engineering Team 2 min read
Subcontracting part of a project safely

Services firms subcontract for good reasons — a specialisation they lack, a capacity spike, a geography they cannot cover. It is normal and it is manageable. What causes trouble is that the client's contract is with you, so the subcontractor's quality, security posture, confidentiality and delivery are all your liability, while their work is the part of the project you have least visibility of.

Start with whether you are permitted. A great many client contracts restrict subcontracting outright or require prior written consent, and enterprise and regulated clients almost always do. Subcontracting in breach of that clause is a serious problem that surfaces at the worst moment, typically during an audit or a dispute. If you need to subcontract and the contract forbids it, the conversation to have is with the client, not with yourself.

The assignment chain is the technical risk that outlives the project. You promised the client ownership of the deliverables; you can only deliver that if the subcontractor has assigned their work to you, and if every individual working for them has assigned to them. A gap anywhere in that chain means you have promised something you do not own, and it will be found during the client's next acquisition diligence rather than during yours. Get the assignment in writing before work starts, not at invoice time.

Flow down the obligations you accepted. Confidentiality, security requirements, data handling and residency restrictions, incident notification timelines, audit rights, insurance. If your client contract requires notification of a security incident within a tight window, a subcontractor who tells you a week later has put you in breach and you will have no defence. These clauses are unglamorous and they are the entire mechanism by which a subcontracted arrangement remains safe.

Manage the work rather than the milestone. A subcontractor delivering in month three, unexamined until then, will deliver something that needs weeks of rework — and you will have no time left. Insist on the same practices you would apply internally: work in your repository where possible, reviewed by your engineers, integrated continuously, with the same test and pipeline standards. If they will not work that way, that is a decision about whether to use them at all.

Be straightforward with the client about who is doing what. Concealing a subcontractor is a short-term convenience and a long-term liability — clients discover it, usually through a name on a pull request or an accent on a call, and the discovery costs more trust than the disclosure would have. Naming the arrangement, explaining why it is the right team for that component, and remaining the single accountable party is a position clients accept readily. Being caught is a position they do not.

Need help with this? Explore our Software Development services. Learn more Back to all news

Keep reading

More on IT Strategy