> For the complete documentation index, see [llms.txt](https://docs.certinext.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.certinext.io/documentation/support-and-resources/service-level-agreement-sla.md). # Service Level Agreement (SLA) ### 1. Overview & Scope CERTInext is committed to delivering reliable, secure, and enterprise-grade Certificate Lifecycle Management (CLM) services. This Service Level Agreement (SLA) defines the service commitments, support model, incident response targets, and escalation framework applicable to the CERTInext platform. This document reflects CERTInext's standard commitments and is aligned with globally recognised service-management practices for certificate authorities and CLM providers. It is structured around three commitment types: (i) certificate issuance handling, (ii) platform availability, and (iii) support responsiveness. **Commitment model.** CERTInext commits to defined **initial response times** during active incidents. In line with leading CA and CLM providers, CERTInext does **not** commit to fixed resolution timeframes, as resolution depends on issue complexity, third-party Certificate Authority (CA) dependencies, and the customer environment. **Applicability.** Specific commitments - including tier entitlements, service credits, and any recovery objectives - are defined in each customer's subscription plan or executed support agreement. Where a conflict exists between this document and an executed agreement, the executed agreement prevails. SLA commitments apply to the CERTInext SaaS platform; On-Premises deployments are governed by the applicable professional services or support agreement. ### 2. Definitions | Term | Meaning | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Core Service Functionality** | Certificate lifecycle operations: enrolment, issuance, renewal, and revocation of digital certificates via the CERTInext platform. | | **Availability** | The percentage of successful platform transactions in a calendar month, measured across Core Service Functionality and excluding Excused Downtime. | | **Initial Response Time** | The interval from valid ticket submission through an official channel to a meaningful acknowledgement by CERTInext Support and commencement of investigation. | | **Excused Downtime** | Periods excluded from Availability calculations, as listed in Section 4.3. | | **Scheduled Maintenance** | Planned maintenance activity notified in advance, during which the platform may be intermittently unavailable. | | **Service Credit** | A credit that may be applied to a customer's account where the availability commitment in the executed agreement is not met; not a cash refund. | ### 3. Certificate Issuance Services CERTInext automates certificate request, issuance, renewal, and deployment through integrations with public and private Certificate Authorities (CAs). The overall issuance timeline depends on several interdependent factors: * CA validation processes and the CA's own internal SLAs; * Certificate type - DV, OV, EV, Private PKI, Device / IoT, and others; * Domain or Organisation Validation requirements and any pending approvals; * Customer-configured approval workflows and delegation rules; * Integration and automation configuration (ACME, SCEP, EST, REST API). For fully automated workflows - such as Private PKI, ACME, or pre-approved certificate templates - CERTInext processes requests immediately once all prerequisites and approvals are satisfied. For pre-vetted domains, where domain or organisation validation has already been completed and cached, issuance is near-instant and typically completes in seconds. | Certificate Type | Validation Level | Issuance Mode | Typical Timeframe | | ------------------------------------- | --------------------------------------- | ----------------------------- | ------------------------- | | Pre-vetted Domain (cached validation) | Validation already completed and cached | Automated (ACME / API) | Seconds | | Domain Validation (DV) | Automated domain ownership check | Automated (ACME / API) | Minutes – 1 hour | | Organisation Validation (OV) | CA-led org vetting required | Automated + CA approval | 1 – 3 business days | | Extended Validation (EV) | Full CA vetting + legal verification | Automated + CA approval | 3 – 7 business days | | Private PKI | Internal / customer-defined policy | Fully automated | Immediate (post-approval) | | Device / IoT Certificates | Template-based | Automated (SCEP / EST / ACME) | Seconds – minutes | **Note:** Timeframes above are indicative. Actual issuance times depend on CA processing, validation completeness, and customer workflow configuration. CERTInext processing time (excluding CA-side and customer-side steps) for automated workflows is near-instant. ### 4. Platform Availability & Service Levels CERTInext SaaS is engineered on a highly available cloud architecture with redundant application components, resilient infrastructure, and continuous health monitoring to deliver enterprise-grade availability. #### 4.1 Availability Architecture | Availability Component | Description | | -------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | **Application Services** | Redundant application nodes with automatic failover and load balancing. | | **Infrastructure** | Multi-zone cloud deployment with no single point of failure. | | **Database Resiliency** | Continuous replication, automated backups, and point-in-time recovery. | | **Health Monitoring** | 24×7 automated monitoring with alerting and auto-remediation for known failure patterns. | | **Disaster Recovery (DR)** | Documented DR plan with Recovery Time Objective (RTO) and Recovery Point Objective (RPO) defined per subscription tier. | #### 4.2 Availability Commitment CERTInext commits to **99.9% availability** of Core Service Functionality, measured monthly and excluding Excused Downtime. Availability is calculated as: > **Availability (%) = (Successful Transactions ÷ Expected Transactions) × 100** Service Credit bands, where applicable, are defined in the customer's subscription or executed support agreement. #### 4.3 Excused Downtime The following are excluded from Availability calculations and from Service Credit eligibility: * Scheduled Maintenance and emergency maintenance performed under Section 8; * Force majeure events beyond CERTInext's reasonable control; * Customer-side causes - misconfiguration, unsupported environments, or firewall / DNS / connectivity issues; * Third-party dependencies - CA processing, cloud infrastructure, or APIs not controlled by CERTInext; * Customer-operated client software - ACME clients, connectors, or agents running in the customer environment; * Suspension or throttling arising from customer breach, non-payment, or abuse; * Transient anomalies of only a few seconds that do not materially impact operations. **Note:** Service Credits, where applicable, are the exclusive remedy for an availability shortfall, are governed solely by the executed agreement, and are issued as account credits or term extensions - not cash refunds. ### 5. Support Tiers CERTInext support is offered in tiers. A customer's purchased tier determines support hours, access channels, and the applicable response targets in Section 6. Tier entitlements are confirmed in the executed agreement. | Capability | Standard | Enterprise | Premium | | ------------------------- | -------------- | -------------------- | -------------------- | | Support hours | Business hours | 24 × 5 | 24 × 7 | | Access channels | Portal, Email | Portal, Email, Phone | Portal, Email, Phone | | Priority queue | - | Yes | Yes | | Service reviews | - | Quarterly | Monthly | | Dedicated Service Manager | - | - | Yes | | Incident / RCA reporting | On request | Yes | Yes (priority) | **Note:** The tier structure follows practices common to leading CA and CLM providers, where higher tiers provide faster response targets, broader hours, and dedicated account management. ### 6. Incident Severity & Response Targets CERTInext follows a structured incident-management process for the identification, response, and escalation of service-impacting incidents. Response targets are measured during the support hours applicable to the customer's tier unless the executed agreement states otherwise. #### 6.1 Severity Levels
SeverityPriorityResponse TimesDescription
CriticalP11 HourComplete service outage or business-critical functionality unavailable, with no acceptable workaround.
HighP22 HoursMajor functionality impaired with significant business impact; a workaround may be available.
MediumP38 HoursPartial loss of functionality or a non-critical issue with moderate business impact.
LowP424 HoursMinor issue, cosmetic defect, documentation request, or general assistance.
#### 6.2 Initial Response Targets Initial response is defined as the acknowledgement of a valid support ticket and the commencement of investigation by CERTInext Support, measured from the time the ticket is successfully submitted through the designated support channels. Response time targets vary based on the customer's subscribed support tier, as specified in the table above. CERTInext is committed to meeting the defined response time targets. However, the overall handling and resolution of an incident may vary depending on factors such as issue complexity, dependencies on third-party Certificate Authorities (CAs) or external service providers, and the customer's environment. Where an immediate permanent resolution is not feasible, CERTInext may provide an interim workaround or mitigation while working towards a permanent fix, using commercially reasonable efforts throughout the incident lifecycle. ### 7. Escalation Management Escalation ensures that stalled or high-impact incidents receive progressively senior attention. CERTInext operates two complementary escalation paths: automatic internal triggers and customer initiated escalation. #### 7.1 Internal Escalation Triggers (Automatic) These triggers operate **automatically** inside CERTInext's service-management system. They require **no customer action** - escalation is initiated by the platform whenever a condition below is met. | Escalation Level | Owner Role | Internal Trigger - Escalation Occurs Automatically When… | | ---------------- | --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Level 0** | Service Desk | A ticket is created - investigation begins immediately at intake. | | **Level 1** | Support Lead / Duty Manager | The initial response target for the severity is missed, or a P1/P2 ticket remains unacknowledged. | | **Level 2** | Service Delivery Management | A P1 shows no status progress within one review cycle of Level 1 ownership, or repeated response-target misses occur on the incident. | | **Level 3** | Senior Management | A P1 remains business-critical without a viable workaround beyond the agreed critical-incident window, or repeated response-target misses occur on one account. | #### 7.2 Customer-Initiated Escalation A customer may request escalation at any time by referencing the existing ticket ID through the official CERTInext support channel. The request is routed to the next escalation level without resetting the original response targets. Escalation contacts are managed internally by role; customers are not required to contact named individuals. ### 8. Planned & Emergency Maintenance CERTInext notifies customers in advance of planned maintenance that may affect platform availability. The following principles govern all maintenance activity: * Scheduled Maintenance is planned during low-usage windows to minimise operational disruption; * Advance notification of at least 48 hours is provided via the platform status page and direct email; * Routine Scheduled Maintenance is kept within a limited monthly window wherever practicable; * Emergency maintenance is performed only to preserve platform security, stability, or continuity, with best-effort notice; * Post-maintenance confirmation is issued once full service restoration is verified. ### 9. Customer Responsibilities Certain commitments in this SLA - including response targets and any Service Credit eligibility - depend on the customer meeting the following responsibilities: * Timely reporting of incidents through the official support channel, with a valid ticket; * Maintaining accurate, current contact information and subscribing to the platform status page; * Cooperating in diagnosis by providing logs, error details, and reasonable access to relevant information; * Operating the platform in supported configurations and following published implementation guidance; * Ensuring customer-side network connectivity, firewall, and DNS settings are correctly configured; * Maintaining a valid subscription in good standing. **Support scope.** Unless separately contracted, support excludes development or integration of third-party products, customised code, configuration of non-CERTInext products, third-party application queries, and third-party product training. ### 10. General Terms & Applicability * The 99.9% availability commitment, RTO/RPO targets, tier entitlements, and Service Credit bands are defined in each customer's subscription or executed support agreement. * SLA commitments apply to the CERTInext SaaS platform; On-Premises deployments are subject to the applicable professional services or support agreement. * Service Credits, where applicable, are the exclusive financial remedy for availability shortfalls and are governed by the executed agreement, not solely by this document. * Where a conflict exists between this document and an executed agreement, the executed agreement prevails. * CERTInext may update this content. Material changes will be communicated through official channels at `docs.certinext.io`. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.certinext.io/documentation/support-and-resources/service-level-agreement-sla.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.