Anjana Data Support Policy

1. PURPOSE, SCOPE AND RELATIONSHIP WITH THE MSA/ORDER

1.1 Purpose. This Support Policy (the “Policy”) defines, in an operationally and contractually consistent manner, the support services provided by Anjana Data to the Customer for (i) the Anjana Data Platform (software) in its Supported Versions, (ii) availability/accessibility Incidents of SaaS Services (if contracted) and (iii) Queries (how-to/questions) within the defined perimeter.

1.2 Incorporation by reference. This Policy may be incorporated by reference into the MSA (as defined in Section 2) and/or the Order. In the event of conflict between (i) the MSA and/or the Order and (ii) this Policy, the MSA and/or the Order shall prevail to the extent applicable.

1.3 Domain separation. This Policy differentiates and separately regulates the following domains, which are not to be confused with one another:

• (A) Product technical support (software) on Supported Versions;

• (B) SaaS Incident Support (only unavailability/inaccessibility of the contracted SaaS service);

• (C) Query Handling (how-to/questions) within perimeter, excluding Professional Services.

2. DEFINITIONS

For the purposes of this Policy, the following terms shall mean:

2.1 “Anjana Data”: the Anjana Data group entity indicated in the MSA/Order.

2.2 “Customer”: the contracting entity indicated in the MSA/Order.

2.3 “MSA” (Master Services Agreement): the master services agreement entered into between Anjana Data and the Customer that governs, among other things, the general conditions applicable to the provision of services and/or licenses covered by the Order, including, where applicable, liability limitations, exclusions, confidentiality and other general terms.

2.4 “Order”: the purchase order/Order Form or commercial annex entered into between the Parties that identifies, among other things, the contracted scope, the applicable time zone, the type of deployment (on-premise/private/SaaS), and any specific conditions.

2.5 “Documentation”: technical/functional documentation published by Anjana Data (including, where applicable, online portal/documentation) applicable to the Anjana Data Platform and/or SaaS Services.

2.6 “SaaS Services”: the Anjana Data SaaS service contracted by the Customer in the Order, whose support obligation for incidents, under this domain, is limited to the availability/accessibility of the service.

2.7 “Support”: the assistance provided by Anjana Data in accordance with this Policy, including (depending on domain) analysis, diagnosis, recommendations, mitigations (“workarounds”), updates, bug fixes and security patches; all subject to exclusions and requirements.

2.8 “Incident”: for Domain 2 (SaaS), an event of unavailability or inaccessibility of the contracted SaaS Service. For Domain 1 (product), an error or anomalous behavior of the software in a Supported Version that affects its operation in accordance with Documentation.

2.9 “Severity”: level assigned to the ticket in accordance with the criteria of this Policy.

2.10 “TOR” (Time of Response): maximum target time for the first acknowledgment and initial response by Anjana Data from the registration of the ticket in the Portal, within applicable business hours. The TOR does not constitute a commitment to resolution or delivery of fixes.

2.11 “TTR” (Time To Restore): for Domain 2 (SaaS), the target for restoring the service to an accessible/available state. The TTR is an operational target, not an absolute guarantee, and is subject to exclusions, dependencies and causes outside reasonable control.

2.12 “Integration Partner”: a third party authorized by the Customer (and accepted by Anjana Data where applicable) to implement/operate/integrate the Anjana Data Platform and act as a technical liaison.

2.13 “Version”, “Patch”, “GA”, “Latest Release”, “Support Window”, “EOS”, “EOL”, “Supported Version”: defined in Section 9.

3. GENERAL SUPPORT PRINCIPLES

3.1 Best-efforts obligation. Anjana Data shall provide Support with reasonable diligence and in accordance with this Policy. Except for the target TTR of Domain 2, this Policy does not establish resolution commitments or fix delivery deadlines.

3.2 Response vs. workaround vs. fix.

• (i) Response: initial communication and diagnostic guidance;

• (ii) Workaround: reasonable mitigation to reduce impact, where feasible;

• (iii) Fix: delivery of a fix via (a) a new Version, (b) an updated installation kit and/or (c) a Patch, per Section 9.

3.3 Versioning condition. Full Support is provided on Supported Versions. If the Customer operates a version in EOS/EOL (End Of Support/End Of Life, see Section 9.2) or outside the Support Window, Anjana Data may require an upgrade as a prerequisite to continue Support with full scope.

3.4 Separation of Professional Services. Design/architecture, implementation, advanced configuration, functional validation, optimization, migrations, custom development, training or change management activities are considered Professional Services and are excluded from Domain 3 unless expressly agreed in the Order.

4. CHANNELS, TICKET REGISTRATION AND INFORMATION REQUIREMENTS

4.1 Single channel (Portal). The Customer shall register tickets exclusively through the Support Portal:
https://support.portal.anjanadata.com/servicedesk/customer/portals

4.2 Mandatory ticket types. The Customer shall select the corresponding type:

• “Technical support” (Domain 1)

• “Incident” (Domain 2 – SaaS availability/accessibility)

• “Query” (Domain 3)

4.3 Minimum information requirements. The Customer (or Integration Partner) shall provide reasonably necessary information, including, where applicable:

• description of the impact and scope (affected users/environments);

• start time and current status;

• steps to reproduce (if applicable);

• relevant evidence and logs, error messages, correlation IDs;

• exact version, components/plugins, relevant configuration;

• recent changes (configuration, deploys, upgrades, network, IAM, certificates, etc.);

• in SaaS: environment, affected URLs, connectivity traces.

4.4 Cooperation and access. When required for diagnosis, the Customer shall provide reasonable remote access, permissions, intervention windows and/or availability of technical personnel. Lack of cooperation or insufficient information may (i) prevent reproduction, (ii) delay diagnosis, and (iii) affect Anjana Data’s ability to propose a workaround or fix.

4.5 Support channel usage guide. Operational information regarding the use of the Support Portal (including, among others, ticket creation and tracking, ticket types, required fields, best practices for providing evidence and communications) is available in the Anjana Data public wiki at:
https://wiki.anjanadata.com/es/portal-de-soporte/current

Note: In the event of discrepancy between said wiki and the MSA/Order or this Policy, the MSA/Order and this Policy shall prevail.

5. SEVERITY CLASSIFICATION, RECLASSIFICATION AND SLAS (TOR/TTR)

5.1 Initial assignment. The Customer shall propose a Severity level when opening the ticket.

5.2 Right of reclassification. Anjana Data may reclassify the Severity at any time, providing justification in the ticket, based on actual impact, reproducibility, scope and existence of a workaround.

5.3 Computation. TORs are computed from the registration of the ticket in the Portal, during the applicable business hours of the domain. Time may be reasonably paused (“waiting on Customer”) when the next action depends on information, access or confirmation from the Customer.

5.4 Severity and SLA Table (by support type)

Contractual note (TOR/TTR/RPO/RTO). (i) The TOR (Time of Response) is the maximum target time for the first acknowledgment and initial response by Anjana Data; TORs do not constitute commitments to resolution or delivery of fixes. (ii) The TTR (Time To Restore) is a service restoration target for SaaS Incidents and not an absolute guarantee, being subject to exclusions and third-party dependencies. (iii) For Domain 2, the RPO (Recovery Point Objective) – 24 hours is the maximum target age of restored data relative to the time of the incident (maximum data loss of up to 24 hours), and the RTO (Recovery Time Objective) – 24 hours is the maximum target to restore the platform to full operation when a restoration is required; the RTO is computed from the restoration request registered by the Customer through the Portal (or contractually accepted channel). (iv) TTR, RPO and RTO are operational targets and not absolute guarantees; they are subject to exclusions, dependencies and Customer cooperation requirements. (v) RPO/RTO do not replace or modify the TOR or TTR, and apply exclusively in scenarios where data/platform restoration is necessary.

6. DOMAIN 1: PRODUCT TECHNICAL SUPPORT (ANJANA DATA PLATFORM – SUPPORTED VERSIONS)

6.1 Scope. Technical support on Supported Versions of the Anjana Data Platform, including:

• maintenance updates/platform improvements or installation kits;

• bug fixes and security patches;

• technical assistance and diagnosis in accordance with TORs.

6.2 Schedule. Business hours 9:00–18:00 in the time zone of the Customer address indicated in the Order, excluding weekends and holidays.

6.3 SLA. Exclusively TOR in accordance with the table in Section 5.4. No resolution SLAs are established.

6.4 Possible deliverables. Depending on the case, Anjana Data may provide:

• diagnostic guidance and recommendations;

• reasonable workaround;

• root cause identification (when feasible);

• delivery of fix per the policy in Section 9 (Latest Release/Patch/future Version).

6.5 Minimum exclusions (product). Anjana Data shall not be obliged to provide Support to the extent that the ticket arises from:

• unauthorized or incompatible use or configuration under the Contract or Documentation;

• general internet problems, force majeure or factors outside reasonable control;

• Customer infrastructure (hardware, software, network, IAM, certificates, etc.);

• third-party systems or components, or acts or omissions of third parties.

Effect of exclusion. If Anjana Data reasonably determines, following minimum checks, that the event falls within an exclusion, Anjana Data may limit or cease Support activities related to the remediation of the excluded cause (including fix, rollback, reconfiguration or reconstruction), and shall communicate such determination and its justification through the ticket. Except as provided for SaaS Services with respect to operations that only Anjana Data can perform (including, where applicable, interventions on persistent data) as per Section 11, remediation shall be the responsibility of the Customer or its Integration Partner. Any assistance exceeding high-level recommendations that requires execution by Anjana Data shall be provided, where appropriate, as Professional Services or under the applicable specific service, formalized in writing.

7. DOMAIN 2: SAAS INCIDENT SUPPORT (AVAILABILITY/ACCESSIBILITY ONLY)

7.1 Limited scope. This domain is limited exclusively to unavailability or inaccessibility of the contracted SaaS Service. It does not cover: functional software errors, configurations, integrations, performance due to Customer loads, or incidents attributable to the Customer’s external dependencies.

7.2 Schedule. 24x7.

7.3 SLAs.

• TOR: 2 hours.

• TTR target (Time To Restore): 8 hours.

7.4 Nature of TTR. The TTR is an operational target subject to:

• the need to verify the scope of the Incident;

• third-party dependencies (e.g., cloud providers, DNS, Customer identity providers);

• Customer cooperation and restoration testing when required;

• exclusions in Section 11.

7.5 Exclusions (SaaS). In addition to the general exclusions, unavailability caused by the following is excluded:

• connectivity interruptions of the Customer or its ISP;

• Customer configuration/operation contrary to Documentation (incl. integrations, IAM policies);

• acts or omissions of third parties outside Anjana Data, including Customer providers.

Effect of exclusion. If Anjana Data reasonably determines, following minimum checks, that the event falls within an exclusion, Anjana Data may limit or cease Support activities related to the remediation of the excluded cause (including fix, rollback, reconfiguration or reconstruction), and shall communicate such determination and its justification through the ticket. Except as provided for SaaS Services with respect to operations that only Anjana Data can perform (including, where applicable, interventions on persistent data) as per Section 11, remediation shall be the responsibility of the Customer or its Integration Partner. Any assistance exceeding high-level recommendations that requires execution by Anjana Data shall be provided, where appropriate, as Professional Services or under the applicable specific service, formalized in writing. The foregoing is without prejudice to the TOR/TTR/RPO/RTO objectives applicable to Domain 2.

8. DOMAIN 3: QUERY HANDLING (HOW-TO / QUESTIONS)

8.1 Scope. Handling of queries within the perimeter:

• functional questions (intended use per Documentation);

• functional configuration;

• technical configuration of platform or plugins in the form of targeted guidance;

• installation in the form of targeted guidance.

8.2 Schedule. Business hours 9:00–18:00 in the time zone of the Customer address indicated in the Order, excluding weekends and holidays.

8.3 SLA. TOR 24 hours. No resolution SLAs are established.

8.4 Exclusions (Queries). The following are outside the perimeter and are considered Professional Services:

• end-to-end design/architecture and implementation;

• advanced or custom configuration, complex optimizations;

• functional validation, Customer QA, acceptance testing;

• operational advisory, organizational governance, processes and training/capacity building.

9. VERSIONING, LIFECYCLE AND BUG FIXING POLICY

9.1 Version nomenclature and definitions

9.1.1 “Version” or “Feature Release”. Format YY.N (e.g., 25.1, 25.2), where:

• YY: last two digits of the publication year;

• N: ordinal of the version published within that year (1, 2, 3…).

9.1.2 “Patch” or “Patch Release”. Format “YY.N Patch P” (e.g., 25.2 Patch 1), where P is the ordinal of the patch.

9.1.3 “GA (General Availability)”. Date from which a Version is considered released for general use.

9.1.4 “Latest Release” (Most recent version). The last YY.N Version published by Anjana Data and, if it exists, its latest active Patch.

9.1.5 “Support Window”. Standard support period of 12 months from the GA date of a Version. However, in the exceptional case where, after those 12 months, no subsequent Version exists in GA/Available status (i.e., the Version remains the Latest Release), said Version shall continue to be considered Supported until the GA date of the next Version published by Anjana Data; from that date, the EOS status of the previous Version shall begin to be computed in accordance with Section 9.2.

9.1.6 “Version within Support Window” and “Supported Version”.
A Version is “within the Support Window” when it has not yet reached EOS. A “Supported Version” is a Version within the Support Window and operated in accordance with Documentation and applicable technical requirements.
Express clarification: “Version within Support Window” does not necessarily equate to being “eligible to receive patches” (see 9.3 and 9.4).

9.2 Version lifecycle policy (states and window)

9.2.1 Standard window. Each Version YY.N is supported for 12 months from its GA date, except for the exceptional case provided in the Support Window definition (Section 9.1.5), in which case the Version shall remain Supported until the GA of a subsequent Version.

9.2.2 States.

1. GA / Available: the version is released and enters the Support Window.

2. Supported: during the Support Window, Anjana Data provides assistance in accordance with this Policy (incl. compatible diagnosis and TOR), subject to exclusions.

3. EOS (End of Support): Upon expiry of the 12 months from GA or, if later, on the GA date of a subsequent Version when the exceptional extension of Section 9.1.5 applies. From EOS, Anjana Data may limit or refuse support for that version and require upgrade to a version in Supported status.

4. EOL (End of Life) (if applicable): subsequent state where Anjana Data does not maintain operational compatibility/telemetry or assistance.

9.2.3 Publication of dates. GA/EOS dates (and EOL if applicable) shall be published in Documentation and/or Support Portal and may be updated with reasonable prior notice.

9.2.4 Recommended upgrade window (recommendation). It is recommended that the Customer maintain its deployment on the Latest Release or, at most, on the immediately prior published Version, in order to reduce risk, facilitate support and maximize receipt of improvements and fixes.

9.3 General bug fix principles

9.3.1 Mitigations. Anjana Data may provide workarounds at its reasonable discretion when a viable mitigation exists.

9.3.2 Mechanism decision. The decision to fix via Patch, incorporate it into a future Version, or prioritize it on the roadmap belongs to Anjana Data, reasonably, considering impact, risk and effort, without prejudice to severity reclassification (Section 5.2).

9.3.3 Dependencies. The fix may depend on reproducibility, access to evidence/logs, Customer environment, third-party dependencies and compliance with cooperation requirements.

9.4 Fix delivery policy (by severity) — “Latest Release” Rule

9.4.1 General rule (Sev 1/2/3). Fixes are delivered in the Latest Release and/or its latest active Patch. To benefit from the fix, the Customer must upgrade to the Latest Release (or its active patch).

9.4.2 Severity 1 Errors.

• Priority handling per TOR, including diagnosis and, where appropriate, workaround.

• Fix delivery: via a Latest Release Patch or via a subsequent Latest Release if necessary.

• Delivery conditioned on Latest Release: Anjana Data is not obliged to issue a Patch for the Customer’s specific version if that version is not the Latest Release, even if it is within the 12-month Support Window. To benefit from the fix, the Customer must upgrade to the Latest Release (and, where applicable, to its latest active Patch), unless expressly agreed in writing in the Order.

9.4.3 Severity 2 Errors.

• Normally incorporated into a planned future Version and/or into a Latest Release Patch if the risk justifies it, at Anjana Data’s reasonable discretion.

9.4.4 Severity 3 Errors.

• Handled by roadmap prioritization. Inclusion on the roadmap does not imply a date commitment unless expressly agreed in the Order.

9.5 Restrictions and contractual consistency

9.5.1 Prohibition of ambiguity. Commitments of the type “as soon as possible” are not established. Delivery is governed by Latest Release/Patch/future Version/roadmap per 9.4.

9.5.2 Express clause. “Response times (TOR) do not constitute commitments to resolution or delivery of fixes.”

9.5.3 EOS/EOL condition. If the Customer operates a version in EOS/EOL or outside the Window, Anjana Data may require upgrade as a condition of full support.

9.5.4 Responsibility for upgrades/updates and platform maintenance modalities.
Unless the Order expressly provides otherwise, the planning, execution and validation of upgrades/updates to the Anjana Data Platform in the Customer’s environments shall be the responsibility of the Customer or its Integration Partner. However, when the Customer has contracted a Platform Maintenance service in the Order, Anjana Data’s participation in updates shall be provided in accordance with the contracted modality:

a) Platform Maintenance – Basic. Anjana Data shall provide remote support during the update executed by the Customer or its Integration Partner, consisting of reasonable technical guidance, prerequisite verification and troubleshooting assistance during agreed windows; the physical execution of the update and actions on the Customer’s systems remain the responsibility of the Customer or its Integration Partner.

b) Platform Maintenance – Premium. Anjana Data shall perform the execution of the update of the Customer’s environments according to the scope, conditions and windows defined in the Order, including the operational tasks necessary to apply the corresponding Version/Patch; the Customer must provide reasonably necessary access, permissions, collaboration and business validations.

c) Customers without contracted Platform Maintenance. For Customers whose contracts/Orders do not include Platform Maintenance, Anjana Data may, at its reasonable discretion, provide limited assistance on a best-effort and non-recurring basis, without this constituting an obligation for Anjana Data to execute updates. In any case, from 2025, Platform Maintenance is a contractual requirement for the ordinary provision of assistance related to upgrades/updates, and must be contracted in Basic or Premium modality as applicable.

d) Scope excess. Any assistance or activity related to upgrades/updates that (i) exceeds what is provided under the contracted modality, or (ii) requires design, implementation, complex migrations, optimization, advanced configuration or extended coordination, shall be considered Professional Services and shall require additional contracting or express written agreement in the Order.

Clarification: This clause does not alter the fix delivery policy (Section 9.4), including the Latest Release rule, nor does it convert TORs into commitments to resolution or delivery.

9.6 Specific exclusions for bug fixes

In addition to the general exclusions:

• non-standard customizations, unsupported integrations or code modifications by third parties;

• incompatibilities due to dependencies/infrastructure outside those indicated in Documentation;

• use of preview/beta features (if applicable): support on a best-effort basis unless expressly agreed in the Order.

10. ESCALATION, COMMUNICATIONS AND STATUS MANAGEMENT

10.1 Ticket statuses. Anjana Data shall communicate the status of the ticket through the Support Portal. Without prejudice to minor operational adjustments, Anjana Data may use the following standard statuses:

a) “L1”: initial review aimed at behavior validation, configuration verification, initial evidence collection and preliminary scope/severity determination.

b) “L2”: advanced review, including log analysis, data, connectivity, traces and detailed technical validation; may include a request for additional information from the Customer.

c) “L3”: escalation to product and/or DevOps teams, as appropriate (including analysis related to the product and/or installation kits), for additional diagnosis, workaround evaluation and/or determination of the fix mechanism per Section 9.

d) “Waiting for customer’s response”: ticket progress is conditioned on verifications, tests, confirmations, access or additional information from the Customer or Integration Partner.

e) “Waiting for business alignment”: ticket progress is conditioned on coordination or decisions with the Customer (e.g., change windows, workaround acceptance, fix prioritization, or confirmation of actions necessary to enable fix delivery per the versioning policy).

Operational/contractual note: The above statuses describe the ticket management phase and do not in themselves imply a commitment to resolution or delivery of fixes; TORs and, where applicable, the target TTR for SaaS Incidents, are governed exclusively by Section 5.

10.2 Internal escalation. Anjana Data may escalate internally to product, security, IT or DevOps teams as appropriate. Internal escalation does not modify SLAs unless expressly agreed.

10.3 Notifications. Notification of progress and fix deliveries shall be made through the Portal ticket and/or the contractually accepted channels in the Order.

11. EXCLUSIONS, LIMITATIONS AND THIRD-PARTY DEPENDENCIES

11.1 General exclusions. Anjana Data shall have no obligation to provide Support to the extent that the event arises from:

• unauthorized use or use contrary to the Contract/Documentation;

• force majeure, general internet problems or other factors outside reasonable control;

• Customer infrastructure (hardware, software, network, security, IAM, certificates, etc.);

• third-party systems or acts/omissions of third parties.

• deployments, installations or updates executed in a manner contrary to the official installer, installation kits or installation/upgrade procedures published by Anjana Data in the Documentation, including (without limitation) unauthorized modifications to the installer, unsupported automations/scripts that alter the prescribed steps, or material deviations from required prerequisites and configurations; in such cases, Anjana Data may deny or limit Support until the Customer regularizes the deployment in accordance with the official procedures or, where appropriate, through Professional Services.

11.2 Limitation due to dependencies. When diagnosis or restoration depends on third parties (including cloud providers, identity services, Customer integrations), the objectives (incl. TTR) shall be interpreted in accordance with reasonable coordination capacity and available information.

11.3 Minimum prior verification and effects of an exclusion.
Before applying a support exclusion established in this Policy, Anjana Data shall carry out reasonable first-level checks to determine whether, on a well-founded basis, the probable cause of the reported event or impact falls within one or more exclusions (e.g., Customer infrastructure, third-party systems, deployment contrary to the official installer, or use/configuration contrary to Documentation/Contract).
Once the applicability of an exclusion has been reasonably determined, Anjana Data may: (i) limit or cease Support activities related to fix, rollback, remediation or changes necessary to resolve the excluded cause; and (ii) communicate to the Customer, through the ticket, the applied exclusion and its operational justification.
Remediation actions, configuration fixes, rollback, environment reconstruction, infrastructure changes or changes in third-party systems shall be the responsibility of the Customer or its Integration Partner.

11.4 Remediation interventions and operations on persistent data. When remediation requires operational actions (including fix, rollback, reconfiguration, environment reconstruction or infrastructure changes), such actions shall be the responsibility of the Customer or its Integration Partner, except in the case of SaaS Services, where certain operations (including interventions on databases, storage or any persistent data managed by Anjana Data) may only be executed by Anjana Data.
In such cases, (i) Anjana Data shall evaluate whether remediation can be performed via standard procedures (e.g., upgrade to Latest Release, restoration per RPO/RTO, or supported automated mechanisms), and (ii) if, exceptionally, a manual intervention on persistent data were necessary, such intervention: (a) does not form part of standard Support; (b) shall only be performed under a specific service and/or Professional Services formalized in writing (including scope, prerequisites, approvals and execution window); and (c) shall be subject to eligibility criteria and reasonable technical safeguards defined by Anjana Data to minimize the risk of data corruption.
Expressly excluded from Support is any incident, degradation or data corruption arising from manual interventions on persistent data performed by the Customer, the Integration Partner or third parties without prior written authorization from Anjana Data or outside the supported procedures; in such cases, Anjana Data may suspend or limit Support for the affected environment until it is regularized.

12. CUSTOMER AND INTEGRATION PARTNER REQUIREMENTS

12.1 Contact points. The Customer shall designate technical and operational contact points with the capacity to:

• provide evidence and approve mitigation actions;

• coordinate testing and restoration validation;

• execute upgrades where applicable.

12.2 Environments and reproducibility. The Customer shall maintain environments and configurations in a manner that allows reasonable reproducibility, in accordance with Documentation.

12.3 Security and access. When access is required, the Customer shall provide it securely and in accordance with its policies, including the necessary windows and minimum permissions.

13. RESERVATION OF RIGHTS AND POLICY CHANGES

13.1 Policy updates. Anjana Data may modify this Policy with reasonable prior notice, by publication on the Support Portal and/or notification to the designated contractual contact.

13.2 Temporal applicability. Unless the MSA/Order provides otherwise, the updated version shall apply to tickets registered from its indicated effective date.

ANNEX A: SEVERITY CLASSIFICATION EXAMPLES (3–6 EXAMPLES)

A.1 Product – Sev 1 (massive critical). After a supported upgrade, the platform fails to start in production for multiple users and no reasonable workaround exists (e.g., systemic failure of the main service).

A.2 Product – Sev 2 (severe degradation). Search module works but with extreme latency affecting multiple users; partial workaround exists (e.g., removing weightings in searches) with significant loss of functionality.

A.3 Product – Sev 3 (non-critical). Visual error in UI or minor behavior with limited impact; simple workaround exists (e.g., retry, change validation).

A.4 SaaS – Incident. Customer tenant is inaccessible (timeouts/HTTP 5xx) from multiple locations and unavailability of the contracted SaaS service is confirmed.

A.5 Query. Question about how to configure a governance rule described in Documentation, or how to enable a standard connector per the guide.