Use the incident response and recovery runbook

Chapter overview

Bottom line: When an incident occurs, first stop unauthorized activity and contact the responsible person. Then use an offline form to classify symptoms, record decisions that contain the risk, protect privacy and security evidence, and hand off escalation and recovery responsibilities. This chapter does not probe, restart, reconfigure, transfer data from, or repair any live system.

Purpose

Use the five-field offline runbook to get incidents to the right people without triggering a live-environment investigation or remediation.

Prepare

A five-box event table without environmental values and a list of existing responsible roles in the organization.

Time

About 15 minutes

System change

Do not restart, restore, or control a live system; create only a de-identified offline incident-response runbook.

Expected result

Classify incident symptoms, preserve de-identified evidence, and assign stop and recovery decisions without performing live response actions.

Stop conditions

• The incident involves unexpected physical movement or a safety risk, or requires the person responsible for the site to take over immediately.
• Unapproved service actions, telegram transmission, group operations, and physical control are prohibited.

Scope and safety boundaries

"Stop" means to stop your own unapproved activity and scope expansion, not to stop production services. Safe work is limited to offline read-only pinned sources, blank forms and anonymous categories. Read-only viewing of any live/running environment is approval-required; this chapter does not provide viewing, detection, or repair methods.

• Safe: Fill in the de-identified symptom category, human responsibility role, stop status, and controlled evidence reference.
• Isolated test: Alternative projects must first have clear written approval, a non-production test environment, administrator presence, limited network exposure, and a proven stop-and-recovery plan; they are not covered in this chapter.
• Approval required: Viewing or changing any running environment falls into this category; the urgency of the event does not automatically cancel approval.
• Never automate: Do not read or write groups, send a KNX telegram, perform ETS programming or downloads, connect a KNX interface or bus, or control physical equipment. The test bus is no exception.

Joining the repository, installing or starting also requires full isolation gates, written approval, approved immutable artifact/image digest and source-to-build attestation. Stop if any item is missing.

If there are concerns about the safety of people, buildings, door locks, lighting, air conditioners, actuators or other entities, stop using this technical form and immediately contact the live-environment person in charge and safety professionals in accordance with the organization's existing emergency procedures.

Core concepts

Pinned sources help distinguish initialization responsibilities, daemon-invocation responsibilities, and documented driver-diagnostic classes. They do not prove the cause, impact, or recovery of a real incident; the disappearance of error text or program-level descriptions does not prove the state of the KNX bus, ETS, integration, or hardware.

Preparation and prerequisites

Prepare a blank five-field form and a list of roles. Collecting excessive information during an incident can expose private data, and recording adjacent events can encourage an unsupported causal inference.

• Symptom classification: Only the function categories, source categories and unknown items that can be described by the user are recorded, and the equipment, address or site name is not recorded.
• Containment decisions: Record decisions about personnel activity, such as "Stop unapproved trial and error," "Restrict public sharing," or "Wait for the responsible role." Do not record system actions.
• Privacy security evidence: The disclosure list only records the evidence category, controlled storage reference, concealment status and evidence limit.
• Escalation responsibility: Use roles such as incident command, live-environment security, privacy review, product responsibility, or external expertise, and leave names and contact information blank.
• Recovery responsibility: Note who has the authority to make decisions outside of this chapter’s independent approval process and what restrictive statements are required to receive the results.

Environment/event timestamps, log timestamps, execution times, hosts, endpoints, device paths, serial numbers, addresses, account numbers, secrets, or details that may be associated with family activities are not allowed. The order only uses abstract labels such as "earliest known symptom", "follow-up notification", and "post-handover status".

Steps

This runbook only instructs personnel to stop, report and hand over. It does not direct the live system.

1. Stop and find someone first. Stop all unapproved trials and public posts; if there are physical safety concerns, immediately contact the live-environment person in charge and safety professionals in accordance with established emergency procedures.
2. Fill in the symptom-classification field. Select only "User Visible Function Category", "Initialization Responsibility Thread", "Daemon Call Responsibility Thread", "Driver File Type" or "Insufficient Information" without specifying the root cause.
3. Complete the containment-decision field. The incident-command role decides which personnel activities must stop, which public information must be restricted, and who takes over. Do not enter service start or stop actions, configuration changes, connection steps, or hardware measures.
4. Fill out the privacy-safe evidence form. Only the controlled evidence reference, evidence category, concealment status, fact and inference boundaries are recorded. Original material remains in a controlled location by authorized actors.
5. Fill out the escalation-responsibility form. Assign roles that should be taken over based on categories such as security, privacy, source version, or unknown responsibility; if a role is missing, stop and notify incident command.
6. Fill out the recovery responsibility form. Specify the role with authority to initiate independent approval decisions and the responsible role for reporting back the assessment results; do not propose candidate remediation or verification actions.
7. Review and handover. The second reviewer confirms that all five fields are complete, with no identification values or live procedures, and then hands the form to the incident command. The status only says "handover", "stopped because evidence is incomplete" or "waiting for responsible role".

Verification and evidence

The completion standard for this chapter is a clear chain of responsibility, not system recovery. Even if an independent process returns a status, this chapter only accepts handover summaries that have been reviewed, de-identified, and accompanied by an evidence limit.

• Symptom classifications describe only functional or documented responsibility categories and do not have root cause claims.
• The risk-containment decision limits only unauthorized personnel activity and information dissemination; it includes no live-system action.
• Public evidence only has controlled references, categories, masking status, unknown matters and evidence limits.
• Escalation responsibilities clearly identify incident command, site security, privacy review, or other responsible roles.
• Recovery responsibility lies with an independent approval process outside of this chapter, which does not have a remediation or verification step.
• There are no commands, probes, restarts, configuration, telegram, ETS, group, physical or bus actions.
• KNX bus, ETS, integration, group operation and physical control results remain unconfirmed.

Follow-up cadence: Review stop conditions regularly with the deployment assessment, and use Help and downloads for guidance on de-identifying records. These resources still do not authorize live-environment operations.

Troubleshooting

• The notification simply says "The system is broken": Rewrite it as the narrowest user-visible symptom category and the root cause remains unknown.
• Someone has started trial and error: Stop further unapproved actions and record the handoff of responsibility. Do not attempt another action as a remedy.
• The complete log has entered the public channel: Stop reposting, limit dissemination in accordance with organizational privacy procedures, and handle in a controlled location with authorized roles.
• Someone asked to probe the endpoint: Refuse. There are no commands or probes in this chapter.
• Some people suggested restarting or changing settings: Refuse. There are no restart, configuration, or remediation procedures in this chapter.
• Someone asked for ETS, group or telegram verification: Refuse. These actions are not within the incident form and must not be automated.
• Incident command role unknown: Stay stopped and find the person in charge according to the organization's existing reporting chain; do not take over the live system on your own.

FAQ