Set the rehearsal boundary
Suggested workflow practice: use this guide only after the custom system, its intended record groups and its handover boundary have already been scoped. The purpose is to agree one controlled restore rehearsal before handover. Its deliverable is a restore-rehearsal acceptance record that says what was attempted, where it was attempted, what was checked, what evidence was retained, and which gaps remain open.
Begin with the dated agreed scope and identify the backup or backup set proposed for rehearsal. Name the system release or environment it relates to, the backup date or reference, and the business owner who can confirm the records that matter. Do not assume that an export is a restorable backup. A portable export can be useful for reading data outside the application; this review instead asks whether the agreed restoration method can recreate an isolated working copy from the proposed backup material.
Keep the boundary deliberately small. This is not a production recovery, a live cutover, a migration rehearsal, a penetration test, an access review, or a new acceptance exercise. It must not overwrite production or change the live operational source. If someone asks to add a new module, integration, report, permission rule or data-cleaning project, log that request separately and keep the restore decision focused on the agreed rehearsal.
- Dated scope is available
- Backup reference is identified
- Production remains untouched
- Review boundary is agreed
Name people and safe destination
Assign three clear functions before work starts. The business owner agrees the meaningful record groups, representative examples and acceptance decision. A qualified technical operator performs the restoration in the agreed isolated destination. A review participant checks the resulting evidence with the owner; this may be one of the first two people where responsibilities remain clear. Record names or roles, not passwords, secret keys or live credentials.
Describe the non-production destination in practical terms. It should be separated from routine production use and should not send messages, create live transactions, alter production records or become a new source for staff work. Agree how the team will recognise that the destination is isolated, and record that observation. The operator should use approved internal procedures; this guide does not provide shell commands or credential-handling steps.
Agree the data approach before restoration. Use synthetic data where it can answer the check. Where authorised test data is necessary, limit it to the agreed purpose and handle it under the organisation's existing arrangements. Do not place unnecessary personal, financial, health or confidential material into a test destination merely because it exists in production. Record the intended data type and any exclusions in the acceptance record.
- Business owner is named
- Technical operator is named
- Isolated destination is described
- Test-data approach is agreed
Agree what restoration must show
Turn a broad statement such as “the backup works” into observable checks. List the in-scope record groups already agreed for the system, such as jobs, customers, tasks, payments, notes or attachments, only where applicable. For each group, choose a small set of representative records. Include ordinary examples and, where relevant, a record with an attachment, a completed record, a current record and a record with a meaningful relationship to another in-scope record.
For every chosen item, record a stable reference, the expected information to read back, and the reviewer who can recognise it. A check might confirm that a known job reference appears, its agreed status and owner can be read, its linked customer is visible, and an agreed attachment can be opened in the isolated destination. Avoid treating a blank screen, a row count alone or a successful file transfer as sufficient evidence.
NCSC guidance says organisations should know how to restore backups and check that important data is present. Apply that principle proportionately: the rehearsal should check the information the business has identified as important, while openly recording what it did not test. It does not establish a recovery-time target, a security certification, complete data accuracy, or an outcome beyond the evidence observed on this occasion.
- Record groups are listed
- References are stable
- Read-back checks are specific
- Exclusions are recorded
Run, observe and decide exceptions
The technical operator restores only into the agreed isolated destination and records the start and completion observations in the acceptance record. The business owner or reviewer then performs the agreed read-back checks. Preserve concise evidence that another reviewer can understand later: backup reference, destination description, restored release where known, selected record references, attachment result, check date, reviewer and result. Do not put secrets or live connection details into the record.
Treat a failed or incomplete result as information, not a reason to quietly change the test. For each exception, state what was expected, what was observed, which check was affected, who owns the next decision and the safe interim position. Examples include an unavailable attachment, a missing record group, an unclear backup reference, an inability to demonstrate isolation, or a restored record whose relationship cannot be read. A technical diagnosis may be needed, but do not label a gap resolved before its observable check has been repeated.
Use three decision outcomes. Accept means all agreed rehearsal checks passed and remaining exclusions are consciously recorded. Accept with open gaps means the owner accepts the stated handover boundary while named gaps have owners and follow-up decisions; it does not mean the gaps disappeared. Do not accept yet means a material agreed check could not be completed or the destination boundary was not demonstrated. The business owner makes the scope decision; qualified operators decide technical actions within their authority.
- Evidence is retained
- Exceptions have owners
- Interim position is safe
- Decision outcome is stated
Use the acceptance record
Original suggested practice: create one restore-rehearsal acceptance record with these fields: system and agreed-scope reference; backup reference and date; rehearsal date; business owner; technical operator; isolated destination description; authorised or synthetic data approach; included record groups; excluded items; selected stable record references; read-back and attachment checks; evidence location or reference; exceptions; decision owner; decision outcome; and follow-up date where needed. Keep it with the release or handover record so the team does not reconstruct the result from chat messages.
Fictional example: Northbay Service Desk has an already accepted internal job system. Its owner agrees that job records, linked customer details, open-task status and one authorised sample attachment are representative. A qualified operator restores the agreed backup into a separated test destination. The reviewer can read the selected job, customer and task records, but the sample attachment cannot be opened. The record states the observed result, excludes a claim that all attachments are available, assigns the attachment investigation to the technical operator, and records “do not accept yet” until that specific check is repeated. No production record is changed.
This guide complements rather than rewrites neighbouring material. Use the portable-export guide when a recipient must open and understand delivered files outside the application. Use workflow acceptance examples for the intended business flow, access-permission guidance for role rights, cutover rehearsal for changing the live record source, support-ownership guidance for routine incidents, and scope or pilot logs for broader requests and feedback. Use SME Systems educational pages earlier when choosing a system category or first workflow; this guide begins only after that decision and build scope exist.
- Acceptance record is complete
- Fictional example is understood
- Related reviews stay separate
- Open gaps have follow-up
中文指南
先定演练边界
建议的流程做法：只在自定义系统、预定记录范围和交接边界已经确定后使用本指南。目标是在交接前同意一次受控的恢复演练。交付物是恢复演练验收记录，说明尝试了什么、在哪里尝试、检查了什么、保留了什么证据，以及哪些缺口尚未关闭。
先查看有日期的已同意范围，并识别拟用于演练的备份或备份组。记录系统版本或相关环境、备份日期或编号，以及能确认重要记录的业务负责人。不要把导出文件当作可恢复备份。可携式导出可帮助人在应用以外阅读资料；本次审阅的问题是：已同意的恢复方法能否从备份材料重建隔离副本。
边界应保持小而清楚。这不是生产恢复、上线切换、迁移演练、渗透测试、权限审阅或新的业务验收。它不得覆盖生产环境，也不得改变正在使用的运营记录来源。若有人提出增加新模块、整合、报表、权限规则或清理资料项目，应另行记录，恢复决定仍只聚焦已同意的演练。
- 已有日期范围
- 备份编号明确
- 生产环境不变
- 演练边界同意
确认人员与环境
开始前指定三个清楚职责。业务负责人同意重要记录组、代表性样本和验收决定。合格技术操作人员在已同意的隔离目的地执行恢复。审阅参与者与负责人核对证据；在职责仍清楚的情况下，可以由前两者之一兼任。记录姓名或角色，不记录密码、密钥或生产凭证。
用实际可理解的方式描述非生产目的地。它应与日常生产使用分开，不发送信息、不产生真实交易、不改动生产记录，也不应成为员工工作的另一套来源。同意团队如何识别它已隔离，并记录该观察结果。操作人员应使用内部已批准流程；本指南不提供命令列或凭证处理步骤。
在恢复前同意数据做法。可回答检查问题时，使用合成数据。必须使用获授权测试资料时，也只限于已同意目的，并按组织现有安排处理。不要只因生产环境中有资料，就把不必要的个人、财务、健康或机密资料放入测试目的地。验收记录应写明资料类型和排除范围。
- 业务负责人已定
- 技术人员已定
- 隔离环境已述
- 测试资料同意
同意可观察检查
把“备份可用”这类宽泛说法转成可观察的检查。列出系统已同意范围内的记录组，例如工作、客户、任务、付款、备注或附件，但仅限确实适用者。每个记录组选择少量代表性记录；可包括一般记录，以及有附件、已完成、进行中或与其他范围内记录有关联的记录。
每一项都记录稳定编号、应读回的信息和能辨认结果的审阅者。检查可以确认某工作编号存在、已同意的状态和负责人可读、关联客户可见，以及已同意附件可在隔离环境打开。不可仅以空白画面、行数或文件传输成功作为充分证据。
NCSC 指引提出，组织应知道怎样恢复备份，并检查重要资料是否存在。可按比例采用这个原则：演练检查业务已标明的重要信息，同时如实记录未测试部分。这不建立恢复时间目标、安全认证、完整资料准确性，或超出本次观察证据的结果。
- 记录组已列明
- 稳定编号可用
- 读回检查具体
- 排除内容已写
执行并处理例外
技术操作人员只在已同意的隔离目的地恢复，并在验收记录写下开始及完成观察。业务负责人或审阅者再进行已同意的读回检查。保留让日后审阅者可理解的简短证据：备份编号、目的地描述、已恢复版本（如已知）、选定记录编号、附件结果、检查日期、审阅者及结果。不要把秘密资料或实际连接资料写进记录。
失败或未完成的结果是信息，不应成为悄悄改测试的理由。每个例外都写明预期、观察到的结果、受影响检查、下一项决定负责人和安全的临时安排。例子包括附件不可用、缺少记录组、备份编号不清、无法证明隔离，或恢复记录的关联无法读出。可能需要技术诊断，但在重复完成可观察检查前，不应把缺口标为已解决。
可使用三种决定结果。接受，表示所有同意的演练检查通过，余下排除项已被有意识记录。带开放缺口接受，表示负责人接受所述交接边界，而具名缺口已有负责人和后续决定；不表示缺口已经消失。暂不接受，表示重要的已同意检查无法完成，或未能证明目的地边界。业务负责人作范围决定；合格操作人员在其权限内决定技术行动。
- 证据已保留
- 例外有人负责
- 临时安排安全
- 决定结果明确
保存验收记录
原创建议做法：建立一份恢复演练验收记录，字段包括：系统及已同意范围编号；备份编号和日期；演练日期；业务负责人；技术操作人员；隔离目的地描述；获授权或合成资料做法；包括的记录组；排除项目；选定稳定记录编号；读回和附件检查；证据位置或编号；例外；决定负责人；决定结果；以及需要时的后续日期。把它与版本或交接记录放在一起，避免团队日后从聊天内容重建结果。
虚构例子：Northbay Service Desk 有一套已验收的内部工作系统。负责人同意以工作记录、关联客户资料、开放任务状态和一个获授权的样本附件作为代表。合格操作人员把已同意备份恢复到分离测试目的地。审阅者可读到选定的工作、客户和任务记录，但样本附件无法打开。记录写下观察结果，不声称所有附件可用，把附件调查交给技术操作人员，并在该项检查重复前记录“暂不接受”。没有生产记录被改动。
本指南是补充，不改写相邻材料。收件人须在应用外打开并理解交付文件时，使用可携式导出指南；检查预定业务流程时，使用工作流验收示例；审阅角色权限时，使用访问权限指南；改变实时记录来源时，使用切换演练；安排日常事故责任时，使用上线后支持责任；较广的新请求或试点反馈则使用范围或例外记录。在更早阶段，先使用 SME Systems 教育页面判断系统类别或首个流程；本指南只从该决定和开发范围已存在时开始。
- 验收记录完整
- 虚构例子清楚
- 相关审阅分开
- 开放缺口跟进
Sources and next step
Discuss your workflow scope with BossFlow · Compare system categories at SME Systems · All articles