Software Development & Delivery Service Terms

Version 2.4 — Publication date: 01/07/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), deployment on the SERVICE RECIPIENT’s cloud infrastructure and software maintenance services, 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;

(g) technical documentation of the deliverables; and

(h) where included in the Service Order, the maintenance plan in clause 11.

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, except for the maintenance plan in clause 11; (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 hours, or a total bank paid once. In monthly banks, hours not used in a month do not roll over. Total banks will be valid for the period stated in the Service Order or, failing that, for six (6) months from the Term Start Date; hours not used at expiry will lapse without refund. 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 writing, through its contractual contact, 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 in writing by the SERVICE RECIPIENT’s contractual contact, 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. MAINTENANCE PLAN

11.1. Purpose. Where included in the Service Order, the SERVICE PROVIDER will provide maintenance and support services for the software components listed in it (the “Covered Components”), through an annual bank of hours, in exchange for an annual fee paid in advance.

11.2. Term. The plan will begin on the acceptance date of the corresponding development, or on the date indicated in the Service Order, and will last twelve (12) months (each period, a “Plan Year”). It will renew automatically for equal periods, unless either Party gives notice of its decision not to renew at least sixty (60) calendar days before the end of the current Plan Year. These rules prevail over clauses 17.3 and 17.4 of the MSA with respect to the plan.

11.3. Covered activities. The plan hours may be used for: (a) correcting errors not covered by the warranty in clause 4.5; (b) adaptations required by new versions of the programming language, the dependencies or third-party interfaces; (c) security updates for vulnerabilities in the dependencies; (d) technical support, usage questions and problem diagnosis; and (e) minor improvements whose estimate does not exceed sixteen (16) hours per request.

11.4. Annual review. The plan includes, without consuming hours, an annual review of each Covered Component covering the state of its dependencies, known vulnerabilities and compatibility with current versions of the programming language, with a report of recommendations.

11.5. Exclusions. The following are not part of the plan and may not be handled with its hours: (a) new features or improvements exceeding the threshold in clause 11.3(e), which will be quoted as new development; (b) correcting problems caused by modifications made by the SERVICE RECIPIENT or third parties, without prejudice to the diagnosis needed to identify their cause consuming plan hours; (c) the SERVICE RECIPIENT’s environment, infrastructure or data; (d) defects in third-party components, for which the SERVICE PROVIDER may propose workarounds; and (e) training.

11.6. Maintained version. The plan covers the version of each Covered Component delivered or maintained by the SERVICE PROVIDER. The SERVICE RECIPIENT will keep the code in a repository to which the SERVICE PROVIDER has access and will report the modifications made by it or by third parties.

11.7. Requests and records. Requests will be submitted through the support channel indicated by the SERVICE PROVIDER. Requests estimated at more than four (4) hours will require the SERVICE RECIPIENT’s prior approval. Hours will be recorded in increments of half (0.5) an hour, and the SERVICE PROVIDER will report their consumption quarterly.

11.8. Response times. Requests that prevent a Covered Component from working in production will be responded to within one (1) business day, and all others within three (3) business days. Resolution is an obligation of means.

11.9. Unused hours. Hours not used at the end of a Plan Year may be carried over only to the immediately following Plan Year, up to a maximum of twenty percent (20%) of the plan’s annual hours. Carried-over hours will be used first and will lapse at the end of that year, without being carried over again. Accordingly, the hours available in a Plan Year will never exceed one hundred and twenty percent (120%) of the plan’s annual hours. Hours not carried over will lapse without refund.

11.10. Nature of the fee. The annual fee remunerates the SERVICE PROVIDER’s availability, the annual review and the response commitment, regardless of the hours actually used, and is non-refundable except in the cases of clause 5.12 of the MSA.

11.11. Additional hours. Once the available hours are used up, additional requests will be handled at the additional-hour rate in the Service Order, with the SERVICE RECIPIENT’s prior written authorization, or by extending the plan.

11.12. Warranty of interventions. Corrections and adaptations made under the plan will carry a thirty (30) calendar day warranty, during which the SERVICE PROVIDER will correct their defects without consuming hours.

11.13. Additional components. New components that the SERVICE PROVIDER develops for the SERVICE RECIPIENT may be added to the plan through an amendment Service Order adjusting the hours and the fee.

11.14. Onboarding assessment. Components not developed by the SERVICE PROVIDER, or developed by it before the plan came into force, will be added to the plan only after an onboarding assessment at the one-off price stated in the Service Order, which covers a review of the state of the code, an update of critical dependencies and minimum documentation. The SERVICE PROVIDER may make onboarding conditional on correcting the assessment’s findings.

11.15. Reactivation. If the plan ends and the SERVICE RECIPIENT wishes to contract it again, reactivation will require a new onboarding assessment of the Covered Components.

11.16. Support without a plan. Without a plan in force, every support or maintenance request will be quoted and carried out through a separate Service Order, at the SERVICE PROVIDER’s standard rates.

12. TERMINATION AND EXIT

12.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.

12.2. Knowledge transfer. The SERVICE PROVIDER will provide up to twenty (20) hours of knowledge transfer sessions at no additional cost. Additional assistance will be governed by clause 17.10 of the MSA.

12.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.