Go-Live & Incident Response Guideline
Department
Summary
Minimum operational playbook for go-live execution and incident response: environment flow (Local → DEV → UAT → Staging → Production), rollback and verification plans, execution steps, and incident triage → contain → communicate → resolve workflow.
Table of Contents
Purpose
This guideline defines the minimum operational playbook for go-live execution and incident response (who does what, what to write in Kiluth Tasks, and what “done” means).
| Outcome |
|---|
| Production changes are executed with clear ownership, and incidents are handled with fast containment and clear communication. |
Prerequisites
Before proceeding with this document, please review the following documents:
| # | Document | Purpose |
|---|---|---|
| 1 | Delivery Production & Resource Allocation Guideline | Understand delivery execution, sprint planning, and work tracking |
| 2 | Onboarding Guideline | Understand how Kiluth uses Kiluth Tasks, Google Workspace, and other core tools |
Scope
This guideline covers:
| Included | |
|---|---|
| 1 | Environment definitions and promotion flow |
| 2 | Go-live execution responsibilities (including rollback) |
| 3 | Minimum incident response workflow and artifacts |
This guideline applies to client project systems — the environments Kiluth builds, ships and operates for a customer.
| Not covered | |
|---|---|
| 1 | Kiluth’s own internal systems (the portal, docs site, chat, company website). Incidents there are handled by Technology directly and recorded in the department’s own notes and runbooks, not through this guideline. |
| 2 | Project-specific deployment runbooks. This guideline does not replace them; if a project needs one, link it from the go-live task. |
Definitions
| Term | Definition |
|---|---|
| Go-live | Release a change into Production (real users / real operations) |
| Rollback | Reverting to a known-safe state when go-live introduces unacceptable risk or failure |
| Incident | An issue in a client’s production system that materially impacts user experience, data correctness, or business operations |
Operating Model (Sprint + Kiluth Tasks + Visibility)
This document follows Kiluth’s standard operating model. See Onboarding Guideline for details on Kiluth Tasks usage, checkpoints, decision points, and handoff processes.
| Operating Model | |
|---|---|
| 1 | Kiluth Tasks is the system of record for work tracking, approvals, and handoffs. |
| 2 | Use checkpoints and decision points: don’t move forward until the previous step is “done”, and branches are explicit. |
| 3 | Handoff order: upstream defines handoff artifacts/exit criteria; downstream defines execution after handoff. |
Environment Overview
| Environment | Description |
|---|---|
| Local | Developer machine for coding and testing |
| DEV | Internal team testing server |
| UAT / DEMO | Client-facing trial environment for validating that functions work correctly per agreement and are acceptable |
| Staging | Pre-production environment that is as close to Production as possible for final testing |
| Production | Live system for real users |
Workflow Summary
Development → Testing → Client validation → Production-like validation → Go live
Local → DEV → UAT/DEMO → Staging → Production
Step-by-Step Process
| Step | |
|---|---|
| 1 | Confirm go-live owner + execution window (who runs the change, when, who is on standby) |
| 2 | Confirm rollback plan exists (what rollback means here + how to execute it) |
| 3 | Confirm verification plan exists (the checklist that declares success) |
| 4 | Execute go-live and record execution notes in Kiluth Tasks |
| 5 | Verify, then communicate outcome (success / rollback / follow-up actions) |
Decision point: go-live outcome
| Outcome | Action |
|---|---|
| Verified (success) | Proceed to hypercare/monitoring plan (if defined) and close the go-live execution task. |
| Not verified (failure / unacceptable risk) | Execute rollback plan, record what happened, and align next steps + new schedule. |
Task Template: Go-live execution (Technology)
| Task Template | |
|---|---|
| Title | Go-live execution (Technology) – [Client Name] – [Project Title] |
| Assignee | Technology owner |
| Description | Please execute go-live for this project. References • Project: [Link] • Delivery go-live task: [Link] Environment path Local → DEV → UAT/DEMO → Staging → Production Rollback plan • Rollback approach (high-level): [Notes/link] Verification plan • What to verify post-release: [Checklist/link] Execution • Go-live datetime: [Datetime] • Execution notes (minimum): what changed + start time + end time + any deviations + who executed Result • Outcome: Verified / Rolled back • Follow-ups (if any): [List/link] |
Incident Response (Minimum)
| Step | |
|---|---|
| 1 | Triage and confirm impact (what is broken, who is affected, severity) |
| 2 | Contain (stop the bleeding: rollback, disable feature, hotfix, mitigation) |
| 3 | Communicate status (AE/PM aligned; client comms when needed) |
| 4 | Resolve and verify |
| 5 | Record a short incident summary and follow-up tasks (prevent recurrence) |
Severity Levels
Set severity from impact, not from how hard the fix looks. When two levels seem to fit, take the higher one.
| Level | What it means |
|---|---|
| High | Production is down, data is at risk, or payments/checkout are broken. Most or all users affected. No workaround. |
| Medium | A feature is broken but the system still works, and there is a workaround. A subset of users affected. |
| Low | Cosmetic, affects one user, or affects a non-production environment only. |
Severity drives what happens next:
| Level | What changes |
|---|---|
| High | Stop other work. Technology owner responds immediately and names an AE/PM as client comms owner before doing anything else. |
| Medium | Fix within the current sprint. Raise it at the weekly cadence rather than interrupting the sprint. |
| Low | Queue as a normal task. No interruption. |
Telling the client
| Level | Do we tell the client? |
|---|---|
| High | Yes, straight away — before the fix, not after. The AE makes the contact; the Technology owner keeps working the incident. |
| Medium | At the next normal update. No separate message needed. |
| Low | No, unless the client reported it — then reply to them directly. |
On a High incident the client will see the problem themselves. Speaking first is a different conversation from being caught after they noticed. Say what is broken, that it is being worked on, and when the next update comes — an early message without a fix in it is still worth sending.
This sets when to speak, not how fast Kiluth must fix. Kiluth has not committed a response or resolution time to any client, and none is stated here.
Internal aim (not a client commitment): a High incident is picked up the same working day. Miss it and nothing is breached — it is a bar for the team to judge against, not a promise made to anyone outside Kiluth.
When personal data may have been exposed
If an incident may have exposed personal data — names, email addresses, phone numbers, ID numbers, anything identifying a real person — a legal clock starts, and it is not Kiluth’s clock.
| Role | Who | Duty |
|---|---|---|
| Data controller | Normally the client. It is their users’ data and they decide what it is used for. | Notifies Thailand’s PDPC, and notifies affected people when the risk to them is high. |
| Data processor | Normally Kiluth. We build and operate the system to the client’s instruction. | Notifies the client, without delay. |
What Kiluth does:
| Action | |
|---|---|
| 1 | Tell the client immediately, in writing. Do not wait for the fix, and do not wait for certainty about the full extent. |
| 2 | State what you know: what data may be affected, roughly how many people, when it started, and whether it is contained. |
| 3 | Say plainly what is still unknown. A partial picture sent now is more useful to the client than a complete one sent late. |
| 4 | Support the client’s investigation and give them what they need for their own filing. |
| 5 | Record it all on the incident task. |
What Kiluth does not do: contact the PDPC, or contact the affected people. Those are the controller’s calls to make. Making them for the client would take a decision that is legally theirs.
The controller’s deadline is short, so Kiluth being slow to report removes time the client needs. Speed here is the whole obligation.
| # | Exceptions to check |
|---|---|
| 1 | Processor is the normal case, not a guarantee. The role follows who decides what the data is used for. If Kiluth chose what to collect or how to use it rather than building to instruction, Kiluth may be a controller, and the regulator deadline becomes Kiluth’s. Raise it rather than assuming. |
| 2 | The contract wins if it is stricter. If a client agreement sets a tighter notification deadline than “without delay”, follow the contract. |
| 3 | Kiluth’s own systems are out of scope here. This guideline covers client project systems (see Scope). |
Hypercare
A short, agreed watch period straight after go-live — typically the first days of live traffic — where the team monitors more closely than normal and responds faster. The window is agreed with the AE at go-live and written on the go-live task. Outside a hypercare window, incidents follow the normal severity rules above.
Task Template: Incident
| Task Template | |
|---|---|
| Title | Incident – [System/Feature] – [Short description] |
| Assignee | Technology owner |
| Description | Impact: [Who is affected / what is broken] Severity: [Low/Medium/High] (see Severity Levels) Start time: [Datetime] Containment: [Actions taken] Current status: [Short] Client comms owner (AE/PM): [Name] Resolution: [What fixed it] Verification: [What checks passed] Follow-ups: [Tasks/links] |
Go-Live Checklist (Technology Use)
Preconditions
| Checklist | |
|---|---|
| 1 | ☐ Go-live owner assigned |
| 2 | ☐ Rollback plan exists (high-level) |
| 3 | ☐ Verification plan exists |
| 4 | ☐ Relevant stakeholders are on standby (as agreed) |
Execution
| Checklist | |
|---|---|
| 1 | ☐ Execution notes recorded in Kiluth Tasks |
| 2 | ☐ Verification completed |
| 3 | ☐ Outcome communicated (success / rollback / next steps) |