SES agreement review checklist

Hello, this is Legal Agent.

System engineering service (SES) contracts are standard fixtures in the IT sector, but their routine nature can obscure serious regulatory risk. Under these arrangements, engineers support a client's development, maintenance, or operations and are paid by hours worked or services rendered. In practice, legal exposure depends far less on formal contractual phrasing than on who exercises real day-to-day supervision.

Legal classification and command-and-control risk

SES is not a statutory category under the Civil Code; legally, most arrangements operate as a quasi-mandate rather than a contract for work, promising diligent service rather than a finished result. The primary legal risk centers on command and control. If engineers employed by the vendor actually work under the client's direction and control, the arrangement may constitute worker dispatch under the Worker Dispatching Act regardless of the contract's heading. A manager's physical presence does not settle the issue; actual work instructions and labor management matter. Failure to comply with the applicable dispatch rules creates legal risk. Explaining business requirements is acceptable; routine business coordination should be distinguished from instructions controlling how the vendor's employees work.

Work scope, hour-settlement bands, and replacement rules

Vague terms like "development support" leave parties uncertain where the baseline fee ends and extra charges begin. Contracts should identify target systems, operational processes, normal working hours, and out-of-hours coverage. If fees use a monthly settlement band (for example, an agreed range of 140 to 180 hours rather than a statutory working-hours limit), terms should specify hourly deduction rates below the floor, surplus rates above the ceiling, and the handling of standby time. Clear rules on engineer replacement and transition expenses are equally necessary to ensure operational flexibility.

Deliverables, intellectual property, and exit procedures

When engineers generate code, design documents, or operational guides without formal delivery milestones, intellectual property rights require explicit separation. Contracts must distinguish client-owned deliverables from the vendor's pre-existing know-how and address open-source license obligations. If engineers touch production databases or personal data, the agreement should govern access controls, incident-notification timelines, and subcontractor oversight, with clear rules for handing over necessary accounts, revoking departing engineers' access, and returning documents at exit.