This Business Continuity and Disaster Recovery Summary explains how Kool&Tech approaches readiness, containment, communication, restoration, validation, and improvement for covered services.
This Business Continuity and Disaster Recovery Summary describes Kool&Tech LLC practices for preparing for, responding to, and recovering from material service disruptions affecting covered services. It is a public control summary, not an internal recovery runbook or a universal service-level commitment.
Business continuity focuses on sustaining or restoring priority business capabilities during disruption. Disaster recovery focuses on restoring technology, data, configurations, integrations, and supporting infrastructure after a material failure or loss event.
Kool&Tech seeks to protect people and information, contain risk, maintain essential communications, restore priority capabilities, preserve evidence, meet contractual obligations, coordinate dependencies, and improve controls after incidents.
BCDR coverage applies only to services expressly identified in an Order Form, Managed Services Schedule, SOW, subscription, hosting schedule, or SLA. Consulting access to a Customer system does not automatically make Kool&Tech responsible for that system continuity.
Continuity responsibilities may include service ownership, technical recovery, security coordination, provider escalation, Customer communication, legal and privacy review, and executive decision-making. Specific owners depend on the affected service and contractual scope.
Planning considers business criticality, architecture, data sensitivity, dependencies, likely failure modes, provider capabilities, recovery alternatives, manual workarounds, geographic factors, and contractual requirements.
Events may include platform outages, network failures, infrastructure faults, storage failure, data corruption, compromised credentials, cyber incidents, configuration errors, software defects, vendor disruption, regional events, utility loss, unavailable personnel, or supply-chain constraints.
Events may be classified according to verified impact, urgency, affected services, number of Customers or users, data and security implications, workaround availability, duration, and recovery complexity. Classification may change as facts develop.
Recovery generally prioritizes safety and containment, secure administrative access, identity and authentication, critical data services, core application functions, essential integrations, Customer access, and lower-priority capabilities. The actual sequence depends on dependencies and the affected architecture.
RTO is a planning target for restoring a defined service or capability after a qualifying disruption. No RTO applies unless the covered service, trigger, measurement window, exclusions, and target are expressly defined in a signed Service Schedule or SLA.
RPO is a planning target for the maximum intended data-loss interval for a defined protected workload. No RPO applies unless the data source, backup or replication method, measurement basis, exclusions, and target are expressly documented.
This summary intentionally does not promise a universal RTO, RPO, uptime percentage, failover capability, backup frequency, recovery location, or service credit. Those commitments require service-specific architecture, pricing, testing, and signed terms.
Resilience measures may include managed cloud platforms, redundancy, replication, configuration management, documented dependencies, environment separation, least privilege, monitored components, recovery procedures, and vendor-supported capabilities where included.
Backup scope depends on the contracted service and may include platform-managed backups, Customer-managed copies, configuration exports, source repositories, database backups, file backups, or provider recovery capabilities. Backup existence does not by itself establish a recovery guarantee.
Restoration may require identifying an appropriate recovery point, validating authorization, preparing a target environment, restoring data or configuration, reconciling dependencies, testing critical functions, documenting exceptions, and obtaining Customer approval when applicable.
Recovery validation may consider record counts, expected transactions, authentication, permissions, integrations, scheduled jobs, configuration, file availability, error logs, workflow behavior, and Customer business testing appropriate to the service.
Failover, alternate regions, secondary environments, manual procedures, or temporary workarounds apply only where technically available, tested, and included. Some services may require restoration in place rather than failover.
Maintenance may include supported updates, certificate awareness, capacity review, configuration review, monitoring, backup review, integration checks, documentation, and provider lifecycle awareness when included in scope.
A security event may require containment before restoration, including revoking access, isolating integrations, rotating credentials, preserving evidence, limiting functionality, or coordinating with providers. Safe recovery may take priority over immediate restoration.
Potential Personal Data incidents are handled under the DPA, Privacy Policy, applicable law, and contractual notification terms. Investigation and notification depend on verified facts, roles, affected data, risk, and legal requirements.
Odoo, Microsoft, hosting providers, communications services, payment providers, carriers, ISPs, DNS, certificate authorities, AI providers, and APIs may be essential dependencies. Kool&Tech may coordinate and escalate but does not control independent-provider recovery.
Odoo Online, Odoo.sh, and self-hosted Odoo have different hosting, backup, access, repository, database, deployment, and recovery responsibilities. Contracted scope must identify the hosting model and ownership of each continuity control.
Microsoft 365, Azure, Entra, Exchange Online, SharePoint, Teams, and Power Platform are operated by Microsoft. Kool&Tech may administer, configure, investigate, and escalate within scope, while Microsoft controls its platform restoration.
Future KoolArchitect continuity planning may address authentication, workspaces, core process functions, Customer Content, exports, integrations, APIs, and AI dependencies. Binding recovery targets will be documented only after architecture and production service plans are established.
Communications may use email, ticketing, telephone, service notices, Customer contacts, provider notices, or a future status page. Updates may describe known impact, affected services, protective actions, workarounds, dependencies, restoration status, and next communication target.
Customers must maintain current authorized support, security, executive, technical, and billing contacts as applicable. Kool&Tech may rely on designated contacts for decisions, access, testing, approvals, and incident communication.
Testing may include backup review, restoration validation, tabletop scenarios, contact review, dependency review, runbook walkthroughs, controlled technical tests, and lessons-learned exercises according to service scope and risk.
A successful test confirms the tested scenario, environment, data, time, and assumptions. It does not guarantee identical results during every real event, vendor outage, cyberattack, regional disruption, or future architecture change.
Customer responsibilities may include business-impact analysis, supported systems, accurate contacts, secure access, user and endpoint controls, internal continuity plans, required exports, Customer-managed backups, testing participation, decisions, vendor accounts, and communication with Customer personnel.
Unless expressly included, Kool&Tech is not responsible for Customer internet, power, facilities, unsupported systems, unlicensed software, unauthorized changes, Customer-controlled backups, independent provider failures, unavailable Customer staff, inaccurate data, or recovery of records never captured by an included backup.
Production data, recovery copies, logs, exports, archives, and backups may follow different lifecycles. Retention and deletion are governed by the Data Retention & Deletion Policy, DPA, Order Form, provider capability, and legal holds.
Kool&Tech may maintain tickets, timelines, decisions, communications, logs, test evidence, provider case references, recovery results, and corrective actions for operational, security, legal, billing, compliance, and improvement purposes.
After a material event, Kool&Tech may review the cause, detection, response, communications, recovery, dependencies, decisions, control effectiveness, Customer actions, vendor performance, and opportunities for improvement.
Corrective actions may include configuration changes, monitoring improvements, documentation, training, architectural recommendations, provider changes, access improvements, additional backups, testing, or separately scoped Professional Services.
Service-specific Order Forms, Managed Services Schedules, SLA Schedules, and DPA terms control their subjects. The Master Services Agreement, Support Policy, Security & Trust Center, Subprocessor List, and Data Retention & Deletion Policy provide the broader framework.
Kool&Tech may update this public summary as services, architecture, vendors, risks, standards, and contractual offerings evolve. Updates do not change a signed recovery commitment unless the governing agreement permits or accepts the change.
Questions about continuity scope, backup ownership, recovery planning, RTO, RPO, testing, or a service-specific BCDR schedule may be sent to info@koolandtech.com. Active incidents should use the authorized support and escalation channels in the Customer agreement.
Contact Kool&Tech to define covered workloads, recovery ownership, backups, RTO, RPO, testing, escalation, communication, and transition requirements.
Back to headingThis Business Continuity and Disaster Recovery Summary explains how Kool&Tech approaches readiness, containment, communication, restoration, validation, and improvement for covered services.
This Business Continuity and Disaster Recovery Summary describes Kool&Tech LLC practices for preparing for, responding to, and recovering from material service disruptions affecting covered services. It is a public control summary, not an internal recovery runbook or a universal service-level commitment.
Business continuity focuses on sustaining or restoring priority business capabilities during disruption. Disaster recovery focuses on restoring technology, data, configurations, integrations, and supporting infrastructure after a material failure or loss event.
Kool&Tech seeks to protect people and information, contain risk, maintain essential communications, restore priority capabilities, preserve evidence, meet contractual obligations, coordinate dependencies, and improve controls after incidents.
BCDR coverage applies only to services expressly identified in an Order Form, Managed Services Schedule, SOW, subscription, hosting schedule, or SLA. Consulting access to a Customer system does not automatically make Kool&Tech responsible for that system continuity.
Continuity responsibilities may include service ownership, technical recovery, security coordination, provider escalation, Customer communication, legal and privacy review, and executive decision-making. Specific owners depend on the affected service and contractual scope.
Planning considers business criticality, architecture, data sensitivity, dependencies, likely failure modes, provider capabilities, recovery alternatives, manual workarounds, geographic factors, and contractual requirements.
Events may include platform outages, network failures, infrastructure faults, storage failure, data corruption, compromised credentials, cyber incidents, configuration errors, software defects, vendor disruption, regional events, utility loss, unavailable personnel, or supply-chain constraints.
Events may be classified according to verified impact, urgency, affected services, number of Customers or users, data and security implications, workaround availability, duration, and recovery complexity. Classification may change as facts develop.
Recovery generally prioritizes safety and containment, secure administrative access, identity and authentication, critical data services, core application functions, essential integrations, Customer access, and lower-priority capabilities. The actual sequence depends on dependencies and the affected architecture.
RTO is a planning target for restoring a defined service or capability after a qualifying disruption. No RTO applies unless the covered service, trigger, measurement window, exclusions, and target are expressly defined in a signed Service Schedule or SLA.
RPO is a planning target for the maximum intended data-loss interval for a defined protected workload. No RPO applies unless the data source, backup or replication method, measurement basis, exclusions, and target are expressly documented.
This summary intentionally does not promise a universal RTO, RPO, uptime percentage, failover capability, backup frequency, recovery location, or service credit. Those commitments require service-specific architecture, pricing, testing, and signed terms.
Resilience measures may include managed cloud platforms, redundancy, replication, configuration management, documented dependencies, environment separation, least privilege, monitored components, recovery procedures, and vendor-supported capabilities where included.
Backup scope depends on the contracted service and may include platform-managed backups, Customer-managed copies, configuration exports, source repositories, database backups, file backups, or provider recovery capabilities. Backup existence does not by itself establish a recovery guarantee.
Restoration may require identifying an appropriate recovery point, validating authorization, preparing a target environment, restoring data or configuration, reconciling dependencies, testing critical functions, documenting exceptions, and obtaining Customer approval when applicable.
Recovery validation may consider record counts, expected transactions, authentication, permissions, integrations, scheduled jobs, configuration, file availability, error logs, workflow behavior, and Customer business testing appropriate to the service.
Failover, alternate regions, secondary environments, manual procedures, or temporary workarounds apply only where technically available, tested, and included. Some services may require restoration in place rather than failover.
Maintenance may include supported updates, certificate awareness, capacity review, configuration review, monitoring, backup review, integration checks, documentation, and provider lifecycle awareness when included in scope.
A security event may require containment before restoration, including revoking access, isolating integrations, rotating credentials, preserving evidence, limiting functionality, or coordinating with providers. Safe recovery may take priority over immediate restoration.
Potential Personal Data incidents are handled under the DPA, Privacy Policy, applicable law, and contractual notification terms. Investigation and notification depend on verified facts, roles, affected data, risk, and legal requirements.
Odoo, Microsoft, hosting providers, communications services, payment providers, carriers, ISPs, DNS, certificate authorities, AI providers, and APIs may be essential dependencies. Kool&Tech may coordinate and escalate but does not control independent-provider recovery.
Odoo Online, Odoo.sh, and self-hosted Odoo have different hosting, backup, access, repository, database, deployment, and recovery responsibilities. Contracted scope must identify the hosting model and ownership of each continuity control.
Microsoft 365, Azure, Entra, Exchange Online, SharePoint, Teams, and Power Platform are operated by Microsoft. Kool&Tech may administer, configure, investigate, and escalate within scope, while Microsoft controls its platform restoration.
Future KoolArchitect continuity planning may address authentication, workspaces, core process functions, Customer Content, exports, integrations, APIs, and AI dependencies. Binding recovery targets will be documented only after architecture and production service plans are established.
Communications may use email, ticketing, telephone, service notices, Customer contacts, provider notices, or a future status page. Updates may describe known impact, affected services, protective actions, workarounds, dependencies, restoration status, and next communication target.
Customers must maintain current authorized support, security, executive, technical, and billing contacts as applicable. Kool&Tech may rely on designated contacts for decisions, access, testing, approvals, and incident communication.
Testing may include backup review, restoration validation, tabletop scenarios, contact review, dependency review, runbook walkthroughs, controlled technical tests, and lessons-learned exercises according to service scope and risk.
A successful test confirms the tested scenario, environment, data, time, and assumptions. It does not guarantee identical results during every real event, vendor outage, cyberattack, regional disruption, or future architecture change.
Customer responsibilities may include business-impact analysis, supported systems, accurate contacts, secure access, user and endpoint controls, internal continuity plans, required exports, Customer-managed backups, testing participation, decisions, vendor accounts, and communication with Customer personnel.
Unless expressly included, Kool&Tech is not responsible for Customer internet, power, facilities, unsupported systems, unlicensed software, unauthorized changes, Customer-controlled backups, independent provider failures, unavailable Customer staff, inaccurate data, or recovery of records never captured by an included backup.
Production data, recovery copies, logs, exports, archives, and backups may follow different lifecycles. Retention and deletion are governed by the Data Retention & Deletion Policy, DPA, Order Form, provider capability, and legal holds.
Kool&Tech may maintain tickets, timelines, decisions, communications, logs, test evidence, provider case references, recovery results, and corrective actions for operational, security, legal, billing, compliance, and improvement purposes.
After a material event, Kool&Tech may review the cause, detection, response, communications, recovery, dependencies, decisions, control effectiveness, Customer actions, vendor performance, and opportunities for improvement.
Corrective actions may include configuration changes, monitoring improvements, documentation, training, architectural recommendations, provider changes, access improvements, additional backups, testing, or separately scoped Professional Services.
Service-specific Order Forms, Managed Services Schedules, SLA Schedules, and DPA terms control their subjects. The Master Services Agreement, Support Policy, Security & Trust Center, Subprocessor List, and Data Retention & Deletion Policy provide the broader framework.
Kool&Tech may update this public summary as services, architecture, vendors, risks, standards, and contractual offerings evolve. Updates do not change a signed recovery commitment unless the governing agreement permits or accepts the change.
Questions about continuity scope, backup ownership, recovery planning, RTO, RPO, testing, or a service-specific BCDR schedule may be sent to info@koolandtech.com. Active incidents should use the authorized support and escalation channels in the Customer agreement.
Contact Kool&Tech to define covered workloads, recovery ownership, backups, RTO, RPO, testing, escalation, communication, and transition requirements.
Back to heading