SES agreement review checklist

Hello, this is Legal Agent.

SES (system engineering service) contracts look, at first glance, like a standard fixture of the IT industry. An engineer is assigned to a client's development, operation or maintenance work and is paid according to hours worked or support provided. In practice they deserve close scrutiny, because the legal risk depends less on the contract's wording than on who actually directs the engineer day to day.

Command and control decides the legal character

"SES" is not a defined contract type under the Civil Code; legally, most SES arrangements are structured as a quasi-mandate rather than a contract for work, promising the performance of services rather than a completed result. The central risk is command and control: if the client gives the engineer direct daily instructions, manages hours and approves leave, and the vendor's own manager is not functioning in practice, the arrangement can be evaluated as disguised contracting (偽装請負), in substance closer to worker dispatch under the Worker Dispatching Act, regardless of the contract's title. A client explaining business requirements is not itself a problem; the risk appears once the client starts tasks that resemble personnel management.

Scope, settlement range and replacement rules

Vague phrases such as "development support" leave both sides guessing where the base fee ends and additional charges begin, so the process, target system, working hours and out-of-hours coverage should be spelled out. Fee clauses should fix whether pay is a fixed monthly amount or hourly, and if a settlement range applies, for example 140 to 180 hours, the deduction rate below it, the excess rate above it, and how standby time is treated. Rules on replacing an absent engineer, and who bears any handover cost, affect how flexible the arrangement is in practice.

Deliverables, information management and termination

Where programs, design documents or operating manuals are produced without being clearly identified as deliverables, IP ownership and any open-source terms need separate attention, distinguishing what belongs to the client from the vendor's general-purpose know-how. Where the engineer accesses production systems or customer data, access rights, incident-notification deadlines and subcontractor management should be addressed, along with account deletion and document return once the engagement ends.