Managed Git Organizations Service Terms
SERVICE-SPECIFIC TERMS
Version [2.2] — Publication date: 01/02/2026
These Service-Specific Terms (the “Git 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 administration, configuration and support services for organizations on Git platforms 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 takes on the management, governance, technical optimization and operational support of the Git-based organizations and code repositories owned or controlled by the SERVICE RECIPIENT, on the platforms and editions specified in the Service Order, including their enterprise editions (e.g., GitHub Enterprise Cloud or Server, GitLab Premium or Ultimate, Bitbucket Cloud Premium or Data Center).
1.2. Included activities. Unless the Service Order restricts the scope, the service comprises:
(a) initial configuration and provisioning of the organization or enterprise architecture;
(b) management of access, teams, roles, permissions and security policies for users and guests (seats);
(c) configuration, maintenance and optimization of continuous integration and deployment (CI/CD) workflows;
(d) preventive security monitoring and configuration audits in accordance with clause 7;
(e) operational technical support for the managed platform in accordance with clause 5;
(f) design, implementation and maintenance of automated validation workflows (e.g., GitHub Actions or equivalent) that run quality and security checks in accordance with the SERVICE RECIPIENT’s documented policies; and
(g) where included in the Service Order, the deployment control service in clause 8.
1.3. Exclusions. Unless expressly included in the Service Order, the following are not part of the service: (a) development, debugging or maintenance of the code of the SERVICE RECIPIENT’s applications; (b) migrations between platforms or bulk repository migrations; (c) administration of the SERVICE RECIPIENT’s own infrastructure, such as self-hosted runners or servers; (d) remediation of vulnerabilities in the SERVICE RECIPIENT’s code, without prejudice to the duty to notify in clause 7.2; (e) formal user training; and (f) support for third-party tools not integrated by the SERVICE PROVIDER.
2. PLATFORM LICENSES AND CONSUMPTION
2.1. Models. The Service Order will state the licensing model: (a) direct, in which the SERVICE RECIPIENT purchases and pays the platform owner directly for the necessary licenses and consumption; (b) managed, governed by clauses 2.2, 2.3 and 2.5; or (c) included, governed by clauses 2.4 and 2.5. In all models, the SERVICE RECIPIENT will be, before the platform owner, the holder of the enterprise account and of the organizations within it, and will use them for its own business.
2.2. Managed model. Under the managed model: (a) the SERVICE RECIPIENT authorizes the SERVICE PROVIDER to purchase, in the name and on behalf of the SERVICE RECIPIENT, the licenses for the seats it requests and the consumption stated in the Service Order, and to pay for them as its agent, in accordance with clause 5.13 of the MSA; (b) the SERVICE RECIPIENT will reimburse the SERVICE PROVIDER the amount actually paid to the platform owner, without margin, together with the taxes, withholdings and transaction costs associated with the payment; and (c) the amounts reimbursed do not constitute consideration for the SERVICE PROVIDER’s Services, whose administration fee is invoiced separately in accordance with the Service Order.
2.3. Advances and seat changes. Under the managed model: (a) the SERVICE RECIPIENT will pay in advance, at the start of each annual licensing cycle, the estimated value of the licenses for the cycle; (b) additional seats will be paid in advance at the time they are requested, for the months remaining in the current cycle, counting the month of the request as a full month, at the platform owner’s current rate; (c) seat reductions will take effect only at the start of the next annual cycle; (d) if the SERVICE RECIPIENT does not make the advance payments, the SERVICE PROVIDER will not be obliged to make payments on its behalf, and the SERVICE RECIPIENT will be responsible for the consequences of non-payment before the platform owner; and (e) upon termination, clause 2.5 will apply.
2.4. Included model. Under the included model: (a) the administration fee covers the cost of the licenses for up to the number of seats stated in the Service Order, for the edition specified there, which the SERVICE PROVIDER pays to the platform owner; (b) the SERVICE RECIPIENT may reassign the included seats among its users in accordance with the platform owner’s reassignment rules, provided that the number of licensed users never exceeds the number of included seats; (c) additional seats will be invoiced at the additional-seat rate stated in the Service Order, for the months remaining in the current annual cycle; (d) the license component of the fee will be deemed a Third-Party Charge for the purposes of clause 5.10 of the MSA, and may be adjusted when the platform owner raises its prices or changes its licensing model; (e) variable platform consumption is not included, unless the Service Order provides otherwise; and (f) upon termination of the Service, the SERVICE PROVIDER will stop paying for the licenses at the end of the current billing cycle with the platform owner, and clause 2.5 will apply.
2.5. Account creation and billing by the SERVICE PROVIDER. Under the managed and included models: (a) the SERVICE PROVIDER may create and purchase the enterprise account on behalf of the SERVICE RECIPIENT, following the platform owner’s procedure for purchases on behalf of customers; (b) the SERVICE RECIPIENT will accept the invitation as the account owner, and the SERVICE PROVIDER will retain the billing manager role for as long as the model remains in place, without prejudice to the administrative roles in clause 3; (c) the SERVICE RECIPIENT will not remove that role or change the payment method without [thirty (30)] calendar days’ prior notice; if it does, the SERVICE PROVIDER will be released from its payment obligation to the platform owner; (d) upon termination of the model, the SERVICE RECIPIENT will register its own payment method before the end of the current cycle and will cooperate in removing the SERVICE PROVIDER’s payment method and billing role; and (e) the SERVICE RECIPIENT will reimburse the SERVICE PROVIDER for any charge the platform owner makes to the SERVICE PROVIDER’s payment method after termination, until its removal is completed.
2.6. Variable consumption. Unless the Service Order includes them under the managed or included models, CI/CD execution minutes, storage, packages, advanced security features and other variable platform consumption will be paid directly by the SERVICE RECIPIENT to the platform owner. The SERVICE PROVIDER will recommend configuring spending limits and alerts, but will not be liable for consumption arising from the SERVICE RECIPIENT’s decisions or workflows.
2.7. Compliance with third-party terms. The SERVICE RECIPIENT will comply with the terms of service and usage policies of the Git platform. The SERVICE PROVIDER will not be responsible for the suspension, penalty or termination of the SERVICE RECIPIENT’s account caused by breach of those terms or by non-payment of its licenses, unless the latter is due to the SERVICE PROVIDER failing to make a payment for which the SERVICE RECIPIENT had provided the funds in good time.
3. ACCESS, CREDENTIALS AND ACCOUNTS
3.1. Permissions. The SERVICE RECIPIENT will grant and keep active the roles necessary to perform the service. The Parties will apply the principle of least privilege: the Owner role will be granted only when indispensable and to the SERVICE PROVIDER personnel identified in the Service Order or in a subsequent written communication.
3.2. Named accounts. Each person of the SERVICE PROVIDER will use an individual account. Shared accounts will not be used. The SERVICE PROVIDER will keep up to date the list of its personnel with access and report changes within [five (5)] business days.
3.3. Multi-factor authentication. The Parties will implement multi-factor authentication for all accounts with access to the managed organization. The SERVICE PROVIDER will not be responsible for unauthorized access arising from the loss, leak or misuse of credentials under the control of the SERVICE RECIPIENT or its collaborators.
3.4. Tokens and applications. The access tokens and integration applications configured by the SERVICE PROVIDER will have the minimum permissions necessary, will be rotated periodically and will be documented.
4. CHANGE MANAGEMENT
4.1. Standard changes. Routine changes within the scope of the service will be carried out by the SERVICE PROVIDER and logged in accordance with clause 4.3.
4.2. Changes requiring approval. The following will require prior written approval, which may be given by email, from an authorized contact of the SERVICE RECIPIENT identified in the Service Order: (a) deleting, archiving or transferring repositories or organizations; (b) changing the visibility of repositories; (c) modifying or disabling branch protections or security rules; (d) rewriting the history of protected branches; (e) granting or revoking the Owner role; (f) modifying the single sign-on or identity provider configuration; and (g) installing third-party applications with organization-level write permissions.
4.3. Change log. The SERVICE PROVIDER will keep a record of the relevant changes it makes and will make it available to the SERVICE RECIPIENT upon request. The platform’s native audit log will serve as a reference.
4.4. Emergencies. In a security emergency, the SERVICE PROVIDER may take immediate containment measures, such as revoking tokens or restricting access, and will inform the SERVICE RECIPIENT within [four (4)] hours.
5. SUPPORT AND SERVICE LEVELS
5.1. Channels and hours. Support will be provided through [email / support portal], during business hours of [Monday to Friday, 8:00 to 18:00, Colombia time], excluding public holidays, except for the severities for which the table indicates extended coverage.
5.2. Severities and times. Times are counted from the logging of the request in the support channel:
| Severity | Description | Response | Mitigation target | Hours |
|---|---|---|---|---|
| Critical (S1) | Organization inaccessible to all users or active security incident | [1 hour] | [4 hours] | [24x7] |
| High (S2) | Key functionality degraded, such as CI/CD halted for main projects | [4 business hours] | [1 business day] | Business |
| Medium (S3) | Partial impact with a workaround available | [1 business day] | [3 business days] | Business |
| Low (S4) | Questions, configuration requests and improvements | [2 business days] | As planned | Business |
5.3. Nature of the targets. Response times are service commitments. Mitigation targets are best-effort goals when the solution depends on the Git platform or other third parties.
5.4. Service credits. If in a calendar month compliance with the response times for severities S1 and S2 falls below [ninety percent (90%)], the SERVICE RECIPIENT will be entitled to a credit of [five percent (5%)] of the monthly service fee, up to a maximum of [fifteen percent (15%)] per month. Credits must be requested within thirty (30) calendar days after the end of the month and will be applied to the next invoice. Credits are the exclusive remedy in accordance with clause 12.6 of the MSA.
5.5. Exclusions. Failures of the Git platform, causes attributable to the SERVICE RECIPIENT and force majeure events do not count toward the service levels.
6. ASSISTANCE SUBJECT TO ADDITIONAL CHARGES
The SERVICE PROVIDER may charge at its current rates, after informing the SERVICE RECIPIENT, for handling: (a) problems caused by the SERVICE RECIPIENT, its Users or third parties hired by it; (b) configurations modified without coordination under clause 10.2; (c) versions or tools that the SERVICE PROVIDER has notified as unsupported; (d) problems arising from not following the SERVICE PROVIDER’s instructions; and (e) the activities excluded in clause 1.3. The SERVICE RECIPIENT will provide the remote access reasonably required to provide the assistance.
7. ORGANIZATION SECURITY
7.1. Monitoring. Preventive monitoring comprises reviewing the alerts from the platform’s native security tools licensed by the SERVICE RECIPIENT (such as dependency alerts, secret scanning and code analysis), checking configurations against the agreed baseline and a [monthly] review of the audit log.
7.2. Findings. The SERVICE PROVIDER will notify the SERVICE RECIPIENT of relevant findings and recommend their remediation. Exposed secrets will be reported within [four (4)] hours of detection. Remediation in the SERVICE RECIPIENT’s code is its own responsibility, unless included in the Service Order.
7.3. Reports. The SERVICE PROVIDER will deliver a [quarterly] report, or at the frequency stated in the Service Order, on the state of the organization, the changes made, security findings and pending recommendations, as well as additional reports upon the SERVICE RECIPIENT’s reasonable request.
7.4. Recommendations not implemented. Where the SERVICE PROVIDER has recommended a security or configuration measure in writing and the SERVICE RECIPIENT does not implement it or authorize its implementation, the SERVICE PROVIDER will not be liable for the damage that such measure would have prevented.
8. DEPLOYMENT CONTROL (OPTIONAL SERVICE)
8.1. Scope. Where included in the Service Order, the SERVICE PROVIDER will provide designated reviewers, automated controls or both, as an approval step before changes are merged into the protected branches indicated in the Service Order.
8.2. Criteria. Reviews will be carried out against criteria documented and approved by the SERVICE RECIPIENT, such as checklists, branch protection rules, test results and security analysis. Undocumented criteria will not be enforceable.
8.3. Nature. Approval verifies compliance with the documented criteria. It does not constitute a certification or a guarantee that the code is free of errors or vulnerabilities. Responsibility for the code, its functional testing and the decision to deploy it remains with the SERVICE RECIPIENT.
8.4. Times. Human reviews will be handled within [___] business hours of the request, and urgent cases in accordance with severity S1 in clause 5.2.
8.5. Emergency deployments. The SERVICE RECIPIENT may authorize in writing emergency deployments without the SERVICE PROVIDER’s approval. In that case, the SERVICE PROVIDER will not be liable for the effects of the deployed change.
8.6. Rejections. The SERVICE PROVIDER may reject changes that do not meet the criteria, stating the reason, without liability for any resulting delays.
9. INTELLECTUAL PROPERTY AND SOURCE CODE
9.1. Code ownership. All source code, documentation, algorithms and data hosted in the managed organizations are the exclusive property of the SERVICE RECIPIENT or its licensors. The SERVICE PROVIDER acquires no rights over them.
9.2. Provider Tools. The automation scripts, connectors, configuration templates and methodologies that the SERVICE PROVIDER implements in the organization are Provider Tools and are licensed in accordance with clause 9.4 of the MSA.
10. EXCLUSIONS AND LIMITS OF TECHNICAL LIABILITY
10.1. Git platform continuity. The SERVICE PROVIDER does not guarantee the availability or uninterrupted operation of the Git platform owner’s infrastructure. Global outages, service degradation or failures of the platform’s API are acts of a third party and are excluded from the service levels.
10.2. Actions of the SERVICE RECIPIENT. The SERVICE PROVIDER will not be liable for failures, data loss, security breaches or outages caused by modifications, configurations or removal of permissions made directly by the SERVICE RECIPIENT’s administrators without prior coordination with the SERVICE PROVIDER.
10.3. Backup. Unless the Service Order includes an external backup service, retention and backups of code and metadata will be governed exclusively by the native capabilities of the Git platform.
11. USERS AND SEATS
11.1. Changes. When the administration fee is calculated per managed user or seat, increases will be invoiced from the month following their activation, at the rate in the Service Order and until the end of the current period. Reductions will take effect at the start of the next Renewal Period, unless the Service Order provides otherwise. License reimbursements under the managed model are governed by clause 2.3 and additional seats under the included model by clause 2.4.
11.2. Measurement. The number of seats will be determined [quarterly] based on the Git platform’s reports, without prejudice to clause 16 of the MSA.
12. EXIT FROM THE SERVICE
Upon termination of the service, the SERVICE PROVIDER will: (a) deliver, within [ten (10)] business days, documentation of the implemented configuration, including the structure of the organization, teams, roles, policies, CI/CD workflows and integrations; (b) transfer the administrative functions to the person designated by the SERVICE RECIPIENT; (c) delete its accounts and revoke the tokens and applications under its control within [five (5)] business days of that transfer; (d) certify in writing the removal of its access; and (e) under the managed and included models, its payment method and billing role will be removed in accordance with clause 2.5. Additional transition assistance will be governed by clause 17.10 of the MSA.