Software Development & Delivery Service Terms

SERVICE-SPECIFIC TERMS

Version [2.2] — Publication date: 01/02/2026

These Service-Specific Terms (the “Development Terms”) supplement and form an integral part of the Master Services Agreement (MSA) entered into between the SERVICE PROVIDER and the SERVICE RECIPIENT. They govern the provision of software development, continuous integration and delivery (CI/CD) and deployment services on the SERVICE RECIPIENT’s cloud infrastructure, contracted through the corresponding Service Order. Capitalized terms not defined here have the meaning given to them in the MSA.

1. SCOPE OF THE SERVICE

1.1. Description. The SERVICE PROVIDER will develop software in accordance with the SERVICE RECIPIENT’s requirements, through teams made up of its staff and, where it deems necessary, contractors, under the direction, methodology and approval processes of the SERVICE PROVIDER.

1.2. Included activities. As stated in the Service Order, the service comprises:

(a) requirements analysis and refinement;

(b) technical and architectural design;

(c) development and testing;

(d) code review and security analysis in accordance with clause 6;

(e) design, implementation and operation of continuous integration and delivery (CI/CD) workflows;

(f) deployment to the SERVICE RECIPIENT’s environments in accordance with clause 7; and

(g) technical documentation of the deliverables.

1.3. Exclusions. Unless expressly included in the Service Order, the following are not part of the service: (a) production operation and ongoing support of the applications; (b) administration of the cloud infrastructure beyond what is necessary for deployments; (c) third-party software licenses and cloud service consumption; (d) end-user training; (e) data migration; and (f) load or penetration testing carried out by third parties.

2. ENGAGEMENT MODELS

2.1. Models. The Service Order will specify one or more of the following models:

(a) Dedicated capacity: a team with the roles and dedication set out in the Service Order, for a monthly fee. The SERVICE PROVIDER organizes the work according to the SERVICE RECIPIENT’s priorities and undertakes to provide the contracted capacity, not a specific result or deliverable.

(b) Hours bank: a number of monthly or total hours. Hours not used in a month [do not roll over / roll over for up to ___ months]. Hours in excess of the bank require the SERVICE RECIPIENT’s prior authorization and will be invoiced at the rate in the Service Order.

(c) Fixed price per deliverable: the scope, deliverables, schedule, payment milestones and acceptance criteria are defined in the Service Order or in a scope annex. Changes are governed by clause 3.3.

2.2. Time records. Under the dedicated capacity and hours bank models, the SERVICE PROVIDER will keep a record of the time spent and report it to the SERVICE RECIPIENT at each billing interval.

3. REQUIREMENTS, PLANNING AND CHANGES

3.1. SERVICE RECIPIENT’s lead. The SERVICE RECIPIENT will designate in the Service Order a lead with authority to prioritize the work, clarify requirements and accept deliverables, who will respond to the SERVICE PROVIDER’s queries within [three (3)] business days. Delays by the SERVICE RECIPIENT will extend deadlines to the same extent and, under the fixed-price model, may give rise to additional costs.

3.2. Planning. Work will be organized in cycles of [two (2)] weeks or according to the methodology stated in the Service Order, with a planning session at the start and a review of results at the end of each cycle.

3.3. Changes. Under the fixed-price model, scope changes will be processed through a change request stating their impact on price and schedule, and will be carried out only once the SERVICE RECIPIENT accepts it in writing, in accordance with clause 4.5 of the MSA. Under the dedicated capacity and hours bank models, changes in priority are managed within the contracted capacity at no additional cost.

4. ACCEPTANCE AND WARRANTY

4.1. Delivery. The SERVICE PROVIDER will give notice of the delivery of each deliverable or increment in a testing or acceptance environment.

4.2. Acceptance period. The SERVICE RECIPIENT will verify the deliverable against the acceptance criteria within [ten (10)] business days of the notice, and will communicate in writing its acceptance or its reasoned rejection, identifying the criteria not met.

4.3. Deemed acceptance. The deliverable will be deemed accepted if the SERVICE RECIPIENT does not respond within the period, or if it deploys the deliverable to production or uses it for production purposes.

4.4. Correction. Upon a reasoned rejection, the SERVICE PROVIDER will correct the non-conformities within a reasonable period and redeliver. The new verification will be limited to the corrections.

4.5. Warranty. For [sixty (60)] calendar days following acceptance, the SERVICE PROVIDER will correct free of charge any defects that prevent the deliverable from meeting the acceptance criteria. Under the dedicated capacity and hours bank models, these corrections will be made as a priority [and without consuming hours]. The warranty does not cover defects caused by modifications made by the SERVICE RECIPIENT or third parties, by changes in the SERVICE RECIPIENT’s environment, data or integrations, or new requirements. This is the exclusive remedy for defects in the deliverables, in accordance with clause 11.2 of the MSA.

5. CODE OWNERSHIP, HOSTING AND HANDOVER

5.1. Ownership. The source code, documentation and other deliverables developed specifically for the SERVICE RECIPIENT constitute Custom Developments, whose economic rights are assigned to the SERVICE RECIPIENT in accordance with clause 9.3 of the MSA upon full payment of the fee for the corresponding deliverable or period. Provider Tools incorporated in them are licensed in accordance with clause 9.4 of the MSA.

5.2. Chain of rights. The SERVICE PROVIDER warrants that it holds, in writing, the assignment of the economic rights of its staff and contractors over what they develop for the SERVICE RECIPIENT, so that it can make the assignment in clause 5.1.

5.3. Code hosting. The Service Order will state the applicable variant: (a) RECIPIENT repositories: the code is hosted from the start in the SERVICE RECIPIENT’s organization, which will grant the SERVICE PROVIDER’s developers the necessary platform access and licenses, at its own cost; or (b) PROVIDER repositories: the code is hosted in an organization of the SERVICE PROVIDER dedicated to the SERVICE RECIPIENT, whose members are the SERVICE PROVIDER’s staff and contractors, and whose licenses the SERVICE PROVIDER bears as part of its fee. In variant (b), representatives of the SERVICE RECIPIENT may be invited as collaborators for review and follow-up, without developing their own products there.

5.4. Copies. In the PROVIDER repositories variant, the SERVICE RECIPIENT may obtain at any time a copy of the code corresponding to the deliverables or periods paid for.

5.5. Transfer. Upon termination of the service, or earlier at the SERVICE RECIPIENT’s request, and once the amounts owed have been paid, the SERVICE PROVIDER will transfer to the organization designated by the SERVICE RECIPIENT, within [ten (10)] business days, the repositories with their history, issues and pull requests, to the extent the platform allows, together with the CI/CD workflow configuration and the technical documentation.

6. SECURE DEVELOPMENT AND QUALITY

6.1. Practices. The SERVICE PROVIDER will apply secure development practices based on recognized references, such as the OWASP guidelines, which will include peer code review, automated testing within the scope stated in the Service Order, static code and dependency analysis, and management of secrets outside the source code.

6.2. Open-source components. The SERVICE PROVIDER will not incorporate components whose licenses would require the SERVICE RECIPIENT’s code to be licensed or disclosed without its prior written approval, and will maintain an inventory of dependencies to be delivered at the SERVICE RECIPIENT’s request.

6.3. Vulnerabilities. The SERVICE PROVIDER will notify the SERVICE RECIPIENT of known vulnerabilities it detects in the code or its dependencies. Their correction will be carried out within the contracted capacity or through a change request, unless it constitutes a defect covered by the warranty in clause 4.5.

6.4. Artificial intelligence tools. The SERVICE PROVIDER may use AI-based programming assistance tools, configured so that the SERVICE RECIPIENT’s code is not used to train models. The resulting code will be reviewed by the SERVICE PROVIDER’s staff and will be governed by clause 5.1. The SERVICE RECIPIENT may restrict their use in the Service Order.

7. CLOUD ENVIRONMENTS AND DEPLOYMENTS

7.1. Cloud ownership. The cloud accounts, subscriptions and resources belong to the SERVICE RECIPIENT, which pays for their consumption directly to the cloud provider, unless the Service Order provides for their payment on behalf of the SERVICE RECIPIENT in accordance with clause 5.13 of the MSA.

7.2. Access. The SERVICE PROVIDER’s access to cloud environments will carry the minimum permissions necessary for each environment, will preferably be granted through identity federation without permanent credentials, will be kept in secret managers and will be revoked upon termination of the service.

7.3. Environments. The Service Order will state the environments (such as development, testing and production) and which of them the SERVICE PROVIDER operates.

7.4. Release to production. Every production deployment will require the approval of an approver designated by the SERVICE RECIPIENT in the Service Order, given through the approval mechanism configured in the CI/CD workflow. The decision to deploy rests with the SERVICE RECIPIENT.

7.5. Rollback. Deployment workflows will include a documented rollback procedure. The SERVICE PROVIDER will carry out the rollback, at no additional cost, in the event of failures attributable to a deployment it performed.

7.6. Exclusions. The SERVICE PROVIDER will not be liable for failures, outages or changes by the cloud provider, or for cloud costs arising from the configuration approved by the SERVICE RECIPIENT or from its use. The SERVICE PROVIDER will recommend configuring budget alerts.

8. DATA

8.1. Test data. The SERVICE PROVIDER will use fictitious or anonymized data in development and testing environments. Access to real data or to production environments containing Personal Data will require the SERVICE RECIPIENT’s written authorization, in which case the DPA will apply in accordance with clause 8.3 of the MSA.

8.2. Confidentiality. The SERVICE RECIPIENT’s code, documentation and technical information constitute Confidential Information under clause 10 of the MSA.

9. STAFF

9.1. Team composition. The SERVICE PROVIDER determines the team composition needed to fulfill the Service Order and may use contractors in accordance with clause 19.3 of the MSA, who will be subject to equivalent confidentiality and rights-assignment obligations.

9.2. Key personnel. If the Service Order identifies key personnel, the SERVICE PROVIDER will not replace them without [fifteen (15)] calendar days’ prior notice, except for reasons beyond its control, and will replace them with people of an equivalent profile with a reasonable handover period at no cost to the SERVICE RECIPIENT.

9.3. Replacement request. The SERVICE RECIPIENT may request, for justified cause, the replacement of a team member.

9.4. Direction of staff. The SERVICE PROVIDER’s staff act under its exclusive direction and subordination. The SERVICE RECIPIENT will channel its requests through the designated leads and will not give such staff instructions on employment matters, in accordance with clause 19.4 of the MSA.

10. LIABILITY

10.1. Nature of the obligations. The SERVICE PROVIDER’s obligations under these Terms are obligations of means, except for meeting the acceptance criteria of deliverables agreed at a fixed price.

10.2. Exclusions. The SERVICE PROVIDER will not be liable for: (a) the SERVICE RECIPIENT’s deployment decisions; (b) modifications made by the SERVICE RECIPIENT or third parties; (c) erroneous requirements, specifications or data supplied by the SERVICE RECIPIENT; or (d) failures of Third-Party Platforms. Clause 12 of the MSA applies.

11. TERMINATION AND EXIT

11.1. Final handover. Upon termination, the SERVICE PROVIDER will carry out the transfer in clause 5.5, hand over the CI/CD workflows and documentation, and revoke its access to the SERVICE RECIPIENT’s environments.

11.2. Knowledge transfer. The SERVICE PROVIDER will provide up to [___] hours of knowledge transfer sessions at no additional cost. Additional assistance will be governed by clause 17.10 of the MSA.

11.3. Work in progress. Under the fixed-price model, the SERVICE RECIPIENT will pay for the work performed up to the effective date of termination in proportion to its progress. Under the other models, it will pay the fees accrued up to that date.