There is a specific moment in the growth of a Singapore technology company when insurance suddenly becomes urgent rather than theoretical.
It usually happens when a project goes wrong. A software implementation misses a critical deadline. A system delivered to a client contains a defect that disrupts their operations. A managed service provider suffers an outage that affects multiple clients. Or a client simply sends a letter alleging that the company's work caused them a financial loss and asking for compensation.
At that point, the technology company's director looks at their insurance policy for the first time in two years and discovers one of three things: the policy does not cover the type of claim being made, the limit is too low to cover the loss being claimed, or the claim is borderline, and nobody is sure whether it falls inside or outside the policy wording.
This post is for technology business owners who want to understand what a well-structured technology liability claim looks like before they face one, not after.
How technology liability claims typically arise
Most technology liability claims do not begin with a dramatic system failure. They begin with a client who is unhappy with a deliverable and a conversation that gradually becomes a dispute.
The pattern is consistent. The technology company delivers a system or service. The client uses it and encounters problems. The problems may be defects, gaps in functionality, performance issues, or integration failures. The client raises them. The technology company works to resolve them, sometimes successfully, sometimes partially. At some point, the client decides the problems are material enough to represent a breach of the contract or a negligent act, and they make a formal demand.
By the time a formal demand arrives, the dispute has usually been running for weeks or months. This matters for insurance purposes because most technology PI policies are claims-made policies: the policy that responds is the one in force when the claim is made and notified to the insurer, not when the work was done. But they also typically include circumstances notification provisions: if the insured becomes aware of circumstances that are likely to give rise to a claim, they must notify the insurer even if the formal claim has not yet been made.
A technology company that is aware of an unhappy client, a dispute about deliverables, or a formal complaint, but does not notify its insurer because no formal claim has been filed yet, may find that the subsequent claim is not covered if the policy has since renewed or changed. Notifying circumstances early, as soon as the company becomes aware that a claim might follow, is one of the most important things a technology company can do to protect its insurance position.
What the insurer needs to know
When a technology liability claim is notified, the insurer will want to understand several things. Getting these facts organised early makes the claims process significantly smoother.
What was the scope of the engagement? The contract or statement of work is the starting point. The insurer needs to understand what the company undertook to do, what the deliverable was, and what the client's expected outcome was.
What went wrong, and when? A clear, factual account of the issue, when it first appeared, how it was communicated, and what steps were taken to address it. The insurer is not looking for an admission of liability at this stage. They are building a picture of the facts.
What is the client claiming? The formal demand or letter of claim, if one exists. The quantum of the claim, what the client says the loss is and how they have calculated it.
What is the company's position? Whether the company accepts that there was an error, disputes the claim in whole or in part, or believes the loss was caused by factors outside its control. The insurer will appoint a lawyer to advise on this, but the company's initial view is useful context.
Has the company made any admissions? Admissions of liability, whether in an email, a meeting, or a client update, can affect the insurer's ability to defend the claim. Most PI policies include a condition that the insured must not admit liability without the insurer's consent. This condition is worth being aware of from the beginning of any dispute, not just when a formal claim arrives.
Common exclusions that catch technology companies out
Contractual liability beyond common law. Most technology PI policies cover the company's legal liability at common law: what a court would hold it responsible for. Where a contract contains specific provisions that create liability beyond what common law would impose, such as liquidated damages clauses, service level penalties, or indemnities to the client for specified events, many policies will not automatically cover these. A liquidated damages clause that specifies S$10,000 per week of delay is a contractual liability, not necessarily a common law liability. Whether it falls within the policy depends on the specific wording.
Deliberate acts. Cover is for negligent errors and omissions, not for deliberate acts or fraudulent conduct. A technology company that knowingly delivers a substandard product does not have an insured claim.
Consequential loss beyond direct financial loss. Some policies limit cover to the direct financial loss the client suffered from the defect, and do not extend to consequential losses such as lost profits, lost business opportunities, or reputational damage to the client. The client's actual claim may include these elements, and the gap between what the client claims and what the policy covers can be material.
Work done before the retroactive date. As discussed in our earlier post on technology liability insurance, a policy with a retroactive date that does not extend back to the beginning of the company's technology work will not respond to claims arising from that earlier work.
Sub-contractor errors. Where the technology company engaged a sub-contractor to perform part of the work and the error originated with the sub-contractor, the policy may not automatically cover this. Some policies extend to cover liability arising from sub-contractors' work; others do not. If the company regularly uses sub-contractors or freelancers, confirming how the policy treats their work is important.
What to do when a claim arrives
The steps in the first 48 hours after receiving a formal claim or a letter that looks like it might become one:
Notify the insurer or your intermediary immediately. Do not wait for the formal claim to be clearer. The circumstances notification requirement means early notification is always better than late.
Do not respond substantively to the client's demand without legal advice. Acknowledge receipt of the communication, but do not make admissions, offer compensation, or deny liability in writing until the insurer's legal team has been engaged.
Preserve all documentation. The project file, the contract, the statements of work, all email correspondence relating to the deliverable and the dispute, and any testing records or handover documentation. The insurer will need this material to assess the claim and instruct lawyers.
Appoint an internal contact for the claim. A named person who manages communication with the insurer and any lawyers they appoint. Consistency in communication reduces the risk of conflicting statements or inadvertent admissions.
Check the policy limit and the defence costs provision. Know what the policy pays, what the limit is per claim, and whether defence costs are paid in addition to or within the limit. This affects how resources are allocated during the defence.
You can read more about our professional indemnity cover on the products page. Our post on Technology Liability Insurance in Singapore covers the full picture of what this cover addresses and who needs it in Singapore.
This article provides general information only. It is not insurance advice. Policy availability, terms, conditions, and exclusions vary by insurer and product, and cover is subject to the full policy wording. Please contact TZY CO for advice on your specific situation.