Chapter 3 · ProjectVIEW ERP Master SaaS Framework The ProjectVIEW ERP Service Level Agreement commits to 99.9% monthly availability of the production environment, a Recovery Point Objective of 15 minutes and a Recovery Time Objective of 4 hours. Incidents are classified P1 to P4 with defined response and resolution (MTTR) targets — a P1 incident gets an immediate response and a 4-hour MTTR target, 24×7×365 — and SLA performance is reported monthly and reviewed quarterly. 99.9%monthly availability (production) 15 minRecovery Point Objective 4 hRecovery Time Objective 4 hP1 MTTR target, 24×7×365 3.1 SLA Overview This Section defines the Service Levels that the Provider commits to achieving in the delivery and support of the Platform. The Provider shall use commercially reasonable endeavours to meet or exceed the Service Levels set out in this Section when providing the Services. Service Levels cover platform availability, incident response, resolution targets, backup and recovery objectives, and associated Service Credits in the event of non-compliance. The SLA applies to the production environment of the Platform only. Non-production environments (development, sandbox/test) are excluded from SLA measurement unless otherwise specified in the Commercial Contract. 3.1 Platform Availability 3.1.1 Service Level Objective (SLO) The Provider commits to a Service Level Objective of 99.9% monthly uptime for the production environment of the Platform, measured as a percentage of total minutes in the applicable calendar month. Metric Target Measurement Period Service Level Objective (SLO) 99.9% Calendar month Maximum Permitted Downtime 43.2 minutes / month Calculated: (1 – 0.999) × 43,200 mins 3.1.2 Availability Calculation Monthly Availability is calculated using the following formula: Availability % = ((Total Minutes – Downtime Minutes) / Total Minutes) × 100 Where: Total Minutes = the total number of minutes in the applicable calendar month Downtime Minutes = the total minutes during which the production environment is unavailable, excluding Scheduled Maintenance and Excluded Events 3.1.3 Scheduled Maintenance The Provider shall perform scheduled maintenance during pre-agreed Maintenance Windows. Scheduled Maintenance is excluded from Availability calculations provided that: (a) The Provider gives the Customer a minimum of 5 Business Days’ advance written notice of scheduled maintenance; (b) Maintenance is scheduled during Off-Peak Hours (between 22:00 and 06:00 local time at the Customer’s primary site), unless otherwise agreed; (c) Total Scheduled Maintenance does not exceed 4 hours per calendar month; (d) The Provider uses commercially reasonable efforts to minimise the duration and impact of each maintenance window. Emergency Maintenance: In the event of a critical security vulnerability or imminent system failure, the Provider may perform emergency maintenance with less than 5 Business Days’ notice. The Provider shall notify the Customer as soon as reasonably practicable and provide a post-maintenance report within 2 Business Days. 3.2 Environment Lifecycle During implementation, the Provider provisions two (2) distinct environments for the Customer: Phase Environment Purpose Implementation Development / Sandbox Configuration, customisation, data migration, integration testing, and Universal User Acceptance Testing (UAT). The Customer and Provider jointly validate all functional requirements prior to Go-Live. Implementation Production The live operational environment for all Authorised Users. Subject to the full SLA metrics defined in this Section 3. 3.2.1 Post Go-Live Environment Transition Upon Go-Live, the environment structure transitions as follows: Environment Post Go-Live Role Purpose Development / Sandbox Staging Environment Becomes the permanent staging environment used for: debugging and fault reproduction, change requests and enhancement development, software updates and patch testing, and Universal User Acceptance Testing (UAT) prior to production deployment. Production Production Environment Continues as the live operational environment. No changes are deployed to production without prior validation and UAT sign-off in the Staging Environment. Universal User Acceptance Testing (UAT): All software changes, patches, updates, and new feature releases must pass through UAT in the Staging Environment before deployment to Production. The Customer shall be given a minimum of 5 Business Days to complete UAT, and deployment to Production requires written Customer sign-off. The Provider shall not deploy any change to the Production Environment without confirmed UAT approval, except in the case of Emergency Maintenance as defined in Section 3.2.3. The Provider shall maintain environment parity between Staging and Production to ensure that UAT results are representative of production behaviour. Both environments shall run identical software versions, configurations, and security policies at all times, differing only in data content. 3.3 Recovery Objectives The Provider commits to the following recovery objectives for the production environment, aligned with the Platform’s Business Continuity and Disaster Recovery (BC/DR) architecture: Metric Target Definition Recovery Point Objective (RPO) 15 minutes The maximum acceptable amount of data loss measured in time. Transaction log backups run every 15 minutes, ensuring no more than 15 minutes of data may be lost in a disaster scenario. Recovery Time Objective (RTO) 4 hours The maximum acceptable duration of service interruption. The Provider shall restore full platform functionality within 4 hours of declaring a disaster event. These recovery objectives are supported by the following backup architecture : Backup Type Frequency Retention Encryption Transaction log backups Every 15 minutes 7 days AES-256 at rest Database full backups Every 12 hours 30 days AES-256 at rest Incremental file backups Daily 30 days AES-256 at rest Weekly full backups Weekly (Sunday) 90 days AES-256 at rest Monthly archival backups Monthly (1st) 12 months AES-256 at rest All backups are stored in geo-redundant Azure storage within the Customer’s designated Azure region, with optional cross-region replication as specified in the Commercial Contract. Backup integrity is verified through automated restoration tests performed quarterly. Azure Backup Overview: https://azure.microsoft.com/en-us/products/backup 3.4 Incident Priority Classification All Incidents reported to the Provider Service Desk (PSD) shall be classified according to the following priority levels: Priority Severity Definition Example P1 Critical Complete system unavailability or critical business function failure affecting all or substantially all Authorised Users. Data integrity at risk. Production server down, critical database corruption, platform entirely inaccessible, data loss event. P2 Urgent Significant degradation of a critical business function. System operational but with severely limited functionality. Major feature unavailable. Key module non-functional (e.g., Cost Control), severe performance degradation, critical integration failure. P3 Major Non-critical function impaired or degraded performance that does not prevent core business operations. A reasonable workaround exists. Report generation failure, non-critical module issue, cosmetic defect impacting usability, minor integration fault. P4 Minor Cosmetic issue, informational request, or enhancement suggestion with no immediate operational impact. UI alignment issue, documentation correction, feature request, general inquiry. Priority classification shall be mutually agreed between the Customer and the Provider at the time of ticket logging. If the Parties cannot agree, the Customer’s classification shall prevail pending review by the Service Delivery Manager at the next scheduled Service Review meeting. P1 and P2 Incidents must be reported by telephone to the Provider Service Desk to ensure immediate attention. P3 and P4 Incidents may be reported by email, the PSD portal, or telephone. 3.5 SLA Response & Resolution Matrix The Provider shall respond to and resolve Incidents within the targets set out in the SLA Matrix below: Priority Response Time MTTR Target Workaround Target Operation Window GOS Target P1 – Critical Immediate 4 Hours Continuous effort until resolved 24 × 7 × 365 98% P2 – Urgent Immediate 8 Hours 15 Business Days 24 × 7 × 365 95% P3 – Major Within 2 Hours 12 Hours 20 Business Days 24 × 7 × 365 93% P4 – Minor Within 4 Hours Next Release Next scheduled release Business Hours 90% Where: Response Time = time from Incident acknowledgement by PSD to first diagnostic action by an assigned engineer MTTR (Mean Time to Repair) = target elapsed time from Incident acknowledgement to full resolution or effective workaround Workaround Target = maximum elapsed time to provide a temporary resolution that restores core business functionality pending permanent fix GOS (Grade of Service) = the percentage of Incidents within each priority level that are resolved within the MTTR target during the measurement period 3.6 SLA Exclusions The following events are excluded from SLA measurement and shall not count as Downtime or impact GOS calculations: (a) Scheduled Maintenance : pre-notified maintenance performed within agreed Maintenance Windows as defined in Section 3.2.3 (b) Security Events : any Downtime resulting from security breaches, DDoS attacks, or emergency security patches applied to protect the Platform and Customer Data (c) Force Majeure : events beyond the reasonable control of the Provider as defined in Section 9 (d) Customer-Caused Delays : delays arising from the Customer’s failure to meet its obligations under Section 2.8, including failure to provide timely information, approval delays, or unauthorised modifications (e) Third-Party Failures : outages in internet connectivity, DNS, or other services not under the Provider’s direct control, including Microsoft Azure platform outages that affect the underlying infrastructure (f) Approval Lifecycle Delays : delays caused by Customer approval workflows or sign-off processes that prevent the Provider from proceeding with resolution activities In the event of an Azure platform outage, the Provider shall provide the Customer with the relevant Microsoft Root Cause Analysis (RCA) report within 5 Business Days of its publication by Microsoft. Azure Service Health: https://azure.microsoft.com/en-us/features/service-health/ Azure Status: https://status.azure.com/ 3.7 SLA Non-Compliance Penalties Where the Provider fails to achieve the SLO or Grade of Service (GOS) targets set out in this Section 3, the Customer is entitled to financial penalties paid by the Provider. The penalty scale, the calculation basis and the caps are set out in each Customer’s Commercial Contract. In summary: (a) Tiered by variance: penalties increase with the size of the shortfall against the target. A small variance within the agreed tolerance carries no penalty. (b) Two measures: both Availability (SLO) and Grade of Service (GOS) performance count towards the penalty, with Availability carrying the greater weight. (c) Direct payment: penalties are paid as a direct financial payment, not a credit note, after the Customer’s claim is validated. A quarterly cap applies. (d) Claim process: the Customer submits a written claim with the relevant Incidents and supporting evidence within 30 days of the end of the month in which the breach occurred. The Provider validates or disputes the claim within 10 Business Days. Disputes go to the Steering Committee. (e) Sole financial remedy: penalties are the Customer’s sole and exclusive financial remedy for failure to meet Service Levels. This does not limit the Customer’s right to terminate the Framework for material breach under Section 7. (f) Exclusions: no penalty is payable where the SLA failure results from an Excluded Event as defined in Section 3.6. 3.8 Additional Licences & New Users Where the Customer elects to add new Authorised Users (additional licences) during the Subscription Term, the following provisions apply: (a) Same SLA Coverage: All Service Levels, performance targets, recovery objectives, and penalty provisions set out in this Section 3 shall apply equally to all additional Authorised Users and licences from the date of activation. There is no reduced or phased SLA for new users. (b) ARR Adjustment: The ARR used for penalty calculations under Section 3.8 shall be recalculated to include the additional licence fees from the date of activation, on a pro-rata basis for the remainder of the applicable measurement period. (c) Environment Consistency: New users shall have access to the same Production and Staging environments. The Provider shall ensure that the Platform scales to accommodate the additional users without degradation of performance or Availability. (d) Onboarding SLA: The Provider shall activate new user accounts within 2 Business Days of receiving a completed licence addition request from the Customer, including role assignment, access provisioning, and initial training materials. (e) Capacity Guarantee: The Provider warrants that the dedicated private sovereign environment has sufficient headroom, or shall be proactively scaled, to support the additional users without impacting the SLO of 99.9% or any GOS targets. The procedure for adding new licences, including pricing and Commercial Contract amendment requirements, is set out in Section 6 (Fees, Invoicing & Payment Terms). 3.9 SLA Reporting & Service Reviews 3.9.1 Monthly SLA Report Upon request by the Client, the Provider may deliver a monthly SLA performance report to the Customer within 10 Business Days of the end of each calendar month. The report shall include: (e) Monthly Availability percentage and comparison against SLO target (f) Total number of Incidents by priority level, with response and resolution times (g) GOS achievement per priority level (h) Backup success rates and any failed backup events (i) Any SLA breaches with root cause analysis and corrective actions (j) Penalty calculations (if applicable) with ARR basis shown (k) Trend analysis comparing performance against prior 3 months 3.9.2 Quarterly Service Review The Parties might conduct a Quarterly Service Review meeting to review SLA performance, discuss service improvement initiatives, and address any outstanding issues. The Provider shall prepare and submit a quarterly service report in the Customer’s agreed format at least 5 Business Days prior to each review meeting. The quarterly report shall include: (l) Consolidated SLA performance across the quarter (m) Major Incident summaries with root cause analysis (n) Service improvement plan updates and progress (o) Capacity and performance trend analysis (p) Change management summary (patches, updates, releases deployed) (q) Forward-looking risk assessment and mitigation plan 3.9.3 Continual Service Improvement The Provider shall maintain a Continual Service Improvement (CSI) register documenting identified improvement opportunities, agreed actions, responsible parties, and target completion dates. The CSI register shall be reviewed at each Quarterly Service Review. 3.10 SLA Governance The following governance structure applies to SLA management: Role Responsibility Frequency Service Delivery Manager (Provider) Primary point of accountability for SLA performance. Owns the monthly SLA report, escalation management, and CSI register. Ongoing Account Manager (Provider) Commercial relationship management. Escalation point for SLA disputes and Service Credit claims. As required Customer IT Liaison Primary Customer contact for day-to-day service management, Incident reporting, and UAT coordination. Ongoing Steering Committee Joint senior management forum for strategic review of the service relationship, major Incident review, and contract-level decisions. Bi-annual The SLA targets set out in this Section shall be reviewed annually at the Steering Committee meeting and may be amended by mutual written agreement of the Parties. Azure SLA Summary: https://azure.microsoft.com/en-us/support/legal/sla/summary/ ITIL Service Level Management: https://www.axelos.com/best-practice-solutions/itil 3.11 Process Register The following table summarises the SLA management processes established in this Chapter, including responsible roles, expected outcomes, and cross-references to related processes in other Chapters. Role Legend: P = Provider | C = Customer | PSD = Provider Service Desk | SDM = Service Delivery Manager | SC = Steering Committee 3.11.1 Process Registry Ref Process Trigger Handler Approver Expected Outcome Cross-Ref P-3.01 Availability Monitoring Continuous (automated) Provider (NOC) SDM 99.9% SLO maintained; alerts on threshold breach § 3.2 P-3.02 Incident Classification Incident reported to PSD PSD Customer / SDM Mutually agreed priority (P1–P4) § 3.5, § 4.3 P-3.03 SLA Performance Measurement Month-end close SDM — Monthly SLA report within 10 BD § 3.10.1 P-3.04 SLA Breach Detection Monthly SLA report reveals breach SDM Provider Account Mgr Penalty calculation initiated § 3.8 P-3.05 Penalty Claim & Payment Customer submits claim within 30 days Provider Finance Provider Account Mgr Financial payment within 30 days of validation § 3.8.2 P-3.06 Quarterly Service Review Quarter-end SDM + Customer IT Liaison Steering Committee Service review completed; CSI register updated § 3.10.2, § 4.10 P-3.07 New User Activation Customer licence addition request Provider (PSD) Customer IT Liaison User active within 2 BD; ARR adjusted pro-rata § 3.9, § 6 P-3.08 Scheduled Maintenance Maintenance window planned Provider (Infra) SDM Maintenance completed; ≤ 4 hrs/month; Customer notified 5 BD prior § 3.2.3 3.11.2 RACI Matrix Process (Ref) Provider PSD Customer SDM SC P-3.01 Availability Monitoring R I I A — P-3.02 Incident Classification — R C A — P-3.03 SLA Measurement — — I R/A I P-3.04 Breach Detection — — I R I P-3.05 Penalty Claim R — R A I P-3.06 Quarterly Review C — R R A P-3.07 User Activation R R A I — P-3.08 Scheduled Maintenance R I I A — R = Responsible (executes) | A = Accountable (sign-off) | C = Consulted | I = Informed | — = Not Involved 3.11.3 Process Flow — SLA Lifecycle Stage Activity Role Output ① Monitor Continuous availability and performance monitoring (Azure Monitor, Defender) Provider (NOC) Real-time alerts; uptime data ② Detect Incident detected or reported via PSD omnichannel PSD / Customer Ticket created → § 4.3 ③ Classify Priority assigned (P1–P4), SLA clock starts PSD + Customer Agreed priority; response timer ④ Resolve Resolution per MTTR target; escalation if needed Provider Engineering Incident resolved → § 4.4 ⑤ Report Monthly SLA report generated; GOS and Availability calculated SDM SLA report → § 3.10.1 ⑥ Review Quarterly Service Review; CSI register updated SDM + Customer + SC CSI actions → § 4.10 ⑦ Penalise If breached: penalty claim, validation, financial payment Customer → Provider Finance Payment within 30 days ← PreviousService Description & ScopeNext →Service Support & Operations See how ProjectVIEW ERP runs in a dedicated cloud environment for your projects. Book a Demo →
Chapter 3 · ProjectVIEW ERP Master SaaS Framework The ProjectVIEW ERP Service Level Agreement commits to 99.9% monthly availability of the production environment, a Recovery Point Objective of 15 minutes and a Recovery Time Objective of 4 hours. Incidents are classified P1 to P4 with defined response and resolution (MTTR) targets — a P1 incident gets an immediate response and a 4-hour MTTR target, 24×7×365 — and SLA performance is reported monthly and reviewed quarterly. 99.9%monthly availability (production) 15 minRecovery Point Objective 4 hRecovery Time Objective 4 hP1 MTTR target, 24×7×365 3.1 SLA Overview This Section defines the Service Levels that the Provider commits to achieving in the delivery and support of the Platform. The Provider shall use commercially reasonable endeavours to meet or exceed the Service Levels set out in this Section when providing the Services. Service Levels cover platform availability, incident response, resolution targets, backup and recovery objectives, and associated Service Credits in the event of non-compliance. The SLA applies to the production environment of the Platform only. Non-production environments (development, sandbox/test) are excluded from SLA measurement unless otherwise specified in the Commercial Contract. 3.1 Platform Availability 3.1.1 Service Level Objective (SLO) The Provider commits to a Service Level Objective of 99.9% monthly uptime for the production environment of the Platform, measured as a percentage of total minutes in the applicable calendar month. Metric Target Measurement Period Service Level Objective (SLO) 99.9% Calendar month Maximum Permitted Downtime 43.2 minutes / month Calculated: (1 – 0.999) × 43,200 mins 3.1.2 Availability Calculation Monthly Availability is calculated using the following formula: Availability % = ((Total Minutes – Downtime Minutes) / Total Minutes) × 100 Where: Total Minutes = the total number of minutes in the applicable calendar month Downtime Minutes = the total minutes during which the production environment is unavailable, excluding Scheduled Maintenance and Excluded Events 3.1.3 Scheduled Maintenance The Provider shall perform scheduled maintenance during pre-agreed Maintenance Windows. Scheduled Maintenance is excluded from Availability calculations provided that: (a) The Provider gives the Customer a minimum of 5 Business Days’ advance written notice of scheduled maintenance; (b) Maintenance is scheduled during Off-Peak Hours (between 22:00 and 06:00 local time at the Customer’s primary site), unless otherwise agreed; (c) Total Scheduled Maintenance does not exceed 4 hours per calendar month; (d) The Provider uses commercially reasonable efforts to minimise the duration and impact of each maintenance window. Emergency Maintenance: In the event of a critical security vulnerability or imminent system failure, the Provider may perform emergency maintenance with less than 5 Business Days’ notice. The Provider shall notify the Customer as soon as reasonably practicable and provide a post-maintenance report within 2 Business Days. 3.2 Environment Lifecycle During implementation, the Provider provisions two (2) distinct environments for the Customer: Phase Environment Purpose Implementation Development / Sandbox Configuration, customisation, data migration, integration testing, and Universal User Acceptance Testing (UAT). The Customer and Provider jointly validate all functional requirements prior to Go-Live. Implementation Production The live operational environment for all Authorised Users. Subject to the full SLA metrics defined in this Section 3. 3.2.1 Post Go-Live Environment Transition Upon Go-Live, the environment structure transitions as follows: Environment Post Go-Live Role Purpose Development / Sandbox Staging Environment Becomes the permanent staging environment used for: debugging and fault reproduction, change requests and enhancement development, software updates and patch testing, and Universal User Acceptance Testing (UAT) prior to production deployment. Production Production Environment Continues as the live operational environment. No changes are deployed to production without prior validation and UAT sign-off in the Staging Environment. Universal User Acceptance Testing (UAT): All software changes, patches, updates, and new feature releases must pass through UAT in the Staging Environment before deployment to Production. The Customer shall be given a minimum of 5 Business Days to complete UAT, and deployment to Production requires written Customer sign-off. The Provider shall not deploy any change to the Production Environment without confirmed UAT approval, except in the case of Emergency Maintenance as defined in Section 3.2.3. The Provider shall maintain environment parity between Staging and Production to ensure that UAT results are representative of production behaviour. Both environments shall run identical software versions, configurations, and security policies at all times, differing only in data content. 3.3 Recovery Objectives The Provider commits to the following recovery objectives for the production environment, aligned with the Platform’s Business Continuity and Disaster Recovery (BC/DR) architecture: Metric Target Definition Recovery Point Objective (RPO) 15 minutes The maximum acceptable amount of data loss measured in time. Transaction log backups run every 15 minutes, ensuring no more than 15 minutes of data may be lost in a disaster scenario. Recovery Time Objective (RTO) 4 hours The maximum acceptable duration of service interruption. The Provider shall restore full platform functionality within 4 hours of declaring a disaster event. These recovery objectives are supported by the following backup architecture : Backup Type Frequency Retention Encryption Transaction log backups Every 15 minutes 7 days AES-256 at rest Database full backups Every 12 hours 30 days AES-256 at rest Incremental file backups Daily 30 days AES-256 at rest Weekly full backups Weekly (Sunday) 90 days AES-256 at rest Monthly archival backups Monthly (1st) 12 months AES-256 at rest All backups are stored in geo-redundant Azure storage within the Customer’s designated Azure region, with optional cross-region replication as specified in the Commercial Contract. Backup integrity is verified through automated restoration tests performed quarterly. Azure Backup Overview: https://azure.microsoft.com/en-us/products/backup 3.4 Incident Priority Classification All Incidents reported to the Provider Service Desk (PSD) shall be classified according to the following priority levels: Priority Severity Definition Example P1 Critical Complete system unavailability or critical business function failure affecting all or substantially all Authorised Users. Data integrity at risk. Production server down, critical database corruption, platform entirely inaccessible, data loss event. P2 Urgent Significant degradation of a critical business function. System operational but with severely limited functionality. Major feature unavailable. Key module non-functional (e.g., Cost Control), severe performance degradation, critical integration failure. P3 Major Non-critical function impaired or degraded performance that does not prevent core business operations. A reasonable workaround exists. Report generation failure, non-critical module issue, cosmetic defect impacting usability, minor integration fault. P4 Minor Cosmetic issue, informational request, or enhancement suggestion with no immediate operational impact. UI alignment issue, documentation correction, feature request, general inquiry. Priority classification shall be mutually agreed between the Customer and the Provider at the time of ticket logging. If the Parties cannot agree, the Customer’s classification shall prevail pending review by the Service Delivery Manager at the next scheduled Service Review meeting. P1 and P2 Incidents must be reported by telephone to the Provider Service Desk to ensure immediate attention. P3 and P4 Incidents may be reported by email, the PSD portal, or telephone. 3.5 SLA Response & Resolution Matrix The Provider shall respond to and resolve Incidents within the targets set out in the SLA Matrix below: Priority Response Time MTTR Target Workaround Target Operation Window GOS Target P1 – Critical Immediate 4 Hours Continuous effort until resolved 24 × 7 × 365 98% P2 – Urgent Immediate 8 Hours 15 Business Days 24 × 7 × 365 95% P3 – Major Within 2 Hours 12 Hours 20 Business Days 24 × 7 × 365 93% P4 – Minor Within 4 Hours Next Release Next scheduled release Business Hours 90% Where: Response Time = time from Incident acknowledgement by PSD to first diagnostic action by an assigned engineer MTTR (Mean Time to Repair) = target elapsed time from Incident acknowledgement to full resolution or effective workaround Workaround Target = maximum elapsed time to provide a temporary resolution that restores core business functionality pending permanent fix GOS (Grade of Service) = the percentage of Incidents within each priority level that are resolved within the MTTR target during the measurement period 3.6 SLA Exclusions The following events are excluded from SLA measurement and shall not count as Downtime or impact GOS calculations: (a) Scheduled Maintenance : pre-notified maintenance performed within agreed Maintenance Windows as defined in Section 3.2.3 (b) Security Events : any Downtime resulting from security breaches, DDoS attacks, or emergency security patches applied to protect the Platform and Customer Data (c) Force Majeure : events beyond the reasonable control of the Provider as defined in Section 9 (d) Customer-Caused Delays : delays arising from the Customer’s failure to meet its obligations under Section 2.8, including failure to provide timely information, approval delays, or unauthorised modifications (e) Third-Party Failures : outages in internet connectivity, DNS, or other services not under the Provider’s direct control, including Microsoft Azure platform outages that affect the underlying infrastructure (f) Approval Lifecycle Delays : delays caused by Customer approval workflows or sign-off processes that prevent the Provider from proceeding with resolution activities In the event of an Azure platform outage, the Provider shall provide the Customer with the relevant Microsoft Root Cause Analysis (RCA) report within 5 Business Days of its publication by Microsoft. Azure Service Health: https://azure.microsoft.com/en-us/features/service-health/ Azure Status: https://status.azure.com/ 3.7 SLA Non-Compliance Penalties Where the Provider fails to achieve the SLO or Grade of Service (GOS) targets set out in this Section 3, the Customer is entitled to financial penalties paid by the Provider. The penalty scale, the calculation basis and the caps are set out in each Customer’s Commercial Contract. In summary: (a) Tiered by variance: penalties increase with the size of the shortfall against the target. A small variance within the agreed tolerance carries no penalty. (b) Two measures: both Availability (SLO) and Grade of Service (GOS) performance count towards the penalty, with Availability carrying the greater weight. (c) Direct payment: penalties are paid as a direct financial payment, not a credit note, after the Customer’s claim is validated. A quarterly cap applies. (d) Claim process: the Customer submits a written claim with the relevant Incidents and supporting evidence within 30 days of the end of the month in which the breach occurred. The Provider validates or disputes the claim within 10 Business Days. Disputes go to the Steering Committee. (e) Sole financial remedy: penalties are the Customer’s sole and exclusive financial remedy for failure to meet Service Levels. This does not limit the Customer’s right to terminate the Framework for material breach under Section 7. (f) Exclusions: no penalty is payable where the SLA failure results from an Excluded Event as defined in Section 3.6. 3.8 Additional Licences & New Users Where the Customer elects to add new Authorised Users (additional licences) during the Subscription Term, the following provisions apply: (a) Same SLA Coverage: All Service Levels, performance targets, recovery objectives, and penalty provisions set out in this Section 3 shall apply equally to all additional Authorised Users and licences from the date of activation. There is no reduced or phased SLA for new users. (b) ARR Adjustment: The ARR used for penalty calculations under Section 3.8 shall be recalculated to include the additional licence fees from the date of activation, on a pro-rata basis for the remainder of the applicable measurement period. (c) Environment Consistency: New users shall have access to the same Production and Staging environments. The Provider shall ensure that the Platform scales to accommodate the additional users without degradation of performance or Availability. (d) Onboarding SLA: The Provider shall activate new user accounts within 2 Business Days of receiving a completed licence addition request from the Customer, including role assignment, access provisioning, and initial training materials. (e) Capacity Guarantee: The Provider warrants that the dedicated private sovereign environment has sufficient headroom, or shall be proactively scaled, to support the additional users without impacting the SLO of 99.9% or any GOS targets. The procedure for adding new licences, including pricing and Commercial Contract amendment requirements, is set out in Section 6 (Fees, Invoicing & Payment Terms). 3.9 SLA Reporting & Service Reviews 3.9.1 Monthly SLA Report Upon request by the Client, the Provider may deliver a monthly SLA performance report to the Customer within 10 Business Days of the end of each calendar month. The report shall include: (e) Monthly Availability percentage and comparison against SLO target (f) Total number of Incidents by priority level, with response and resolution times (g) GOS achievement per priority level (h) Backup success rates and any failed backup events (i) Any SLA breaches with root cause analysis and corrective actions (j) Penalty calculations (if applicable) with ARR basis shown (k) Trend analysis comparing performance against prior 3 months 3.9.2 Quarterly Service Review The Parties might conduct a Quarterly Service Review meeting to review SLA performance, discuss service improvement initiatives, and address any outstanding issues. The Provider shall prepare and submit a quarterly service report in the Customer’s agreed format at least 5 Business Days prior to each review meeting. The quarterly report shall include: (l) Consolidated SLA performance across the quarter (m) Major Incident summaries with root cause analysis (n) Service improvement plan updates and progress (o) Capacity and performance trend analysis (p) Change management summary (patches, updates, releases deployed) (q) Forward-looking risk assessment and mitigation plan 3.9.3 Continual Service Improvement The Provider shall maintain a Continual Service Improvement (CSI) register documenting identified improvement opportunities, agreed actions, responsible parties, and target completion dates. The CSI register shall be reviewed at each Quarterly Service Review. 3.10 SLA Governance The following governance structure applies to SLA management: Role Responsibility Frequency Service Delivery Manager (Provider) Primary point of accountability for SLA performance. Owns the monthly SLA report, escalation management, and CSI register. Ongoing Account Manager (Provider) Commercial relationship management. Escalation point for SLA disputes and Service Credit claims. As required Customer IT Liaison Primary Customer contact for day-to-day service management, Incident reporting, and UAT coordination. Ongoing Steering Committee Joint senior management forum for strategic review of the service relationship, major Incident review, and contract-level decisions. Bi-annual The SLA targets set out in this Section shall be reviewed annually at the Steering Committee meeting and may be amended by mutual written agreement of the Parties. Azure SLA Summary: https://azure.microsoft.com/en-us/support/legal/sla/summary/ ITIL Service Level Management: https://www.axelos.com/best-practice-solutions/itil 3.11 Process Register The following table summarises the SLA management processes established in this Chapter, including responsible roles, expected outcomes, and cross-references to related processes in other Chapters. Role Legend: P = Provider | C = Customer | PSD = Provider Service Desk | SDM = Service Delivery Manager | SC = Steering Committee 3.11.1 Process Registry Ref Process Trigger Handler Approver Expected Outcome Cross-Ref P-3.01 Availability Monitoring Continuous (automated) Provider (NOC) SDM 99.9% SLO maintained; alerts on threshold breach § 3.2 P-3.02 Incident Classification Incident reported to PSD PSD Customer / SDM Mutually agreed priority (P1–P4) § 3.5, § 4.3 P-3.03 SLA Performance Measurement Month-end close SDM — Monthly SLA report within 10 BD § 3.10.1 P-3.04 SLA Breach Detection Monthly SLA report reveals breach SDM Provider Account Mgr Penalty calculation initiated § 3.8 P-3.05 Penalty Claim & Payment Customer submits claim within 30 days Provider Finance Provider Account Mgr Financial payment within 30 days of validation § 3.8.2 P-3.06 Quarterly Service Review Quarter-end SDM + Customer IT Liaison Steering Committee Service review completed; CSI register updated § 3.10.2, § 4.10 P-3.07 New User Activation Customer licence addition request Provider (PSD) Customer IT Liaison User active within 2 BD; ARR adjusted pro-rata § 3.9, § 6 P-3.08 Scheduled Maintenance Maintenance window planned Provider (Infra) SDM Maintenance completed; ≤ 4 hrs/month; Customer notified 5 BD prior § 3.2.3 3.11.2 RACI Matrix Process (Ref) Provider PSD Customer SDM SC P-3.01 Availability Monitoring R I I A — P-3.02 Incident Classification — R C A — P-3.03 SLA Measurement — — I R/A I P-3.04 Breach Detection — — I R I P-3.05 Penalty Claim R — R A I P-3.06 Quarterly Review C — R R A P-3.07 User Activation R R A I — P-3.08 Scheduled Maintenance R I I A — R = Responsible (executes) | A = Accountable (sign-off) | C = Consulted | I = Informed | — = Not Involved 3.11.3 Process Flow — SLA Lifecycle Stage Activity Role Output ① Monitor Continuous availability and performance monitoring (Azure Monitor, Defender) Provider (NOC) Real-time alerts; uptime data ② Detect Incident detected or reported via PSD omnichannel PSD / Customer Ticket created → § 4.3 ③ Classify Priority assigned (P1–P4), SLA clock starts PSD + Customer Agreed priority; response timer ④ Resolve Resolution per MTTR target; escalation if needed Provider Engineering Incident resolved → § 4.4 ⑤ Report Monthly SLA report generated; GOS and Availability calculated SDM SLA report → § 3.10.1 ⑥ Review Quarterly Service Review; CSI register updated SDM + Customer + SC CSI actions → § 4.10 ⑦ Penalise If breached: penalty claim, validation, financial payment Customer → Provider Finance Payment within 30 days ← PreviousService Description & ScopeNext →Service Support & Operations See how ProjectVIEW ERP runs in a dedicated cloud environment for your projects. Book a Demo →