What the commitment covers
The P1 reaction time applies to every client and every system in scope, at any hour. It is not reserved for a premium tier. Each contract defines the rest of the service: the systems in scope, service hours for lower priorities, reaction targets for P2 to P4, escalation contacts and reporting. Where this page shows [x], the figure is set per contract.
Three different times matter in an incident, and they are kept apart:
- Reaction time. From the moment the incident is reported or detected until a qualified engineer is working on it. This is the time Cloudtech commits to.
- Restoration time. Until service is restored or a workaround is in place. For P1, work continues without interruption until then.
- Resolution time. Until the underlying cause is fixed. This may need a vendor patch, a planned change or a hardware replacement, and is tracked through problem management.
How a P1 is handled
A P1 is reported by phone and recorded as a ticket, or raised directly by Cloudtech’s monitoring. From then on:
- An engineer reacts within one hour and takes ownership.
- The client’s named contact is informed and kept informed at the agreed interval.
- Work continues around the clock until service is restored. Escalation to senior engineers and management follows agreed steps.
- Emergency changes needed to restore service are made under the emergency change procedure and recorded.
- After restoration, the incident is reviewed and the cause is followed to resolution.
What Cloudtech needs from you during a P1: an authorised contact who can be reached throughout, the access agreed for the service, and decisions on failover, restore or emergency changes when they are needed. Where a contact cannot be reached, Cloudtech proceeds with the actions agreed in advance.
Change management
Every production change is planned, approved, recorded and reversible. In ITIL 4 terms this practice is called change enablement.
- Standard changes are low-risk, repeatable and pre-approved, such as adding a database user or extending a tablespace within agreed limits. They follow a documented procedure.
- Normal changes are assessed for risk and impact, approved by the agreed change authority and scheduled in a maintenance window. Examples are an upgrade, a configuration change to a cluster or a new pipeline.
- Emergency changes are made only to restore service during an active P1, approved by the emergency change authority, and reviewed afterwards.
Every change states what changes, why, how it is tested, how it is rolled back, and when it happens. Configuration is kept in version control and applied by automation wherever possible, so the record of a change is the change itself. Cloudtech does not change your application code or business data without your approval.
Post-incident reviews and problem management
Every P1 is followed by a written post-incident review within [x] working days. It records the timeline, the impact, the cause, what worked and what did not, and the actions that prevent a repeat. Reviews are blameless: they examine systems and procedures, not individuals. Actions are tracked until they are closed. Recurring incidents of any priority are investigated as problems, and known errors are recorded with their workarounds.
Reporting and service reviews
Each reporting period, every managed-services client receives a service report, typically monthly. It covers:
- service-level attainment by priority;
- incidents and their durations, post-incident reviews and open problems;
- changes by type, including any rolled back;
- planned maintenance for the next period;
- availability of the systems in scope;
- capacity and performance trends, with forecasts;
- backup results and restore tests;
- patch status and versions approaching end of support;
- access and security events;
- recommendations and open actions on both sides.
The report is discussed in a regular service review, [quarterly] by default.
Security and access
- Named accounts for every engineer; no shared logins.
- Access over secured channels, agreed with the client.
- Credentials in server-side configuration with restricted permissions, never in git or in command lines.
- Read-only access wherever the task allows it; production systems are not queried for reporting.
- Administrative actions and changes recorded for audit.
- Personal data processed only on the client’s documented instructions, under a written agreement, as GDPR Article 28 requires of a processor. Breaches are reported to the client without undue delay (GDPR Article 33(2)).
Onboarding and exit
Onboarding starts with evidence. Cloudtech inventories the systems in scope and measures them. It reads the existing documentation and the last year’s incidents, and agrees access, contacts, maintenance windows and actions agreed in advance. Monitoring is set up against a declared inventory of what should be running. Runbooks are written or validated before the service level starts.
Exit is planned as carefully as onboarding. Documentation, configuration repositories and runbooks are handed over, a transition period is agreed, and Cloudtech’s access is removed at the end. For financial-sector clients, contracts carry the service-location, audit, data-return and exit terms that DORA Article 30 requires.