Hybrid cloud operational handbook

Draft client turnover companion to Enterprise Architecture & Operations · Research current through 6 October 2026

Use established service-management practices and cloud operating guidance, then map them to the client's cloud/GSS boundary, existing investments and actual authority. Incident restoration, major-incident coordination, requests and changes need consistent ownership and evidence across both pipeline-delivered and retained workloads. Their execution paths can differ. Public DoD sources confirm operational automation in defined environments, although they disclose much less about unattended mission-application recovery and its authorization. We recommend designing a bounded response capability now, with adoption governed by evidence for each action. AI can assist investigation; it is neither necessary for routine automation nor a source of permission to execute. This handbook informs reference architecture, standards mapping and the sequence of acquisition, integration and configuration; it does not constitute completed client operating procedures.

Turn over the client record alongside Enterprise Architecture & Operations

The client turnover handbook accompanies Enterprise Architecture & Operations. Its job is to connect the recommended cloud/GSS architecture to the client's boundary, investments, responsibilities and remaining completion work. The source summaries below explain recommendations; they do not replace the applicable standards, licensed handbooks or client procedures. Each adopted requirement must point to the exact source, edition and section, followed by the client's applicability decision. An inaccessible edition or unverified section remains an unresolved variable until the client supplies authoritative evidence.

Populate this concise turnover record from Foundations and the architecture decisions. Keep existing capabilities that meet the need, and distinguish recommended actions from commitments or completed implementation.

Use one linked row per requirement or recommendation: requirement → exact source → local decision/action → owner → dependency → acceptance evidence. For example, a change-control entry can reference DESMF III section 9.3.3 only as historical research context while the client verifies its adopted edition and corresponding section. The completion action is to resolve that applicability and approved change pattern with the responsible owner, not to claim compliance from this report. Record current architecture decisions and accepted evidence separately from recommendations awaiting approval. The resulting handover is a traceable completion sequence; client teams still develop and authorize executable procedures within their own scope.

Existing authorities supply the practice; Foundations supplies applicability

The starting point is an authority register, not a new best-practice framework. Record each source's edition, applicable service/boundary, adopting authority and unresolved conflict. Distinguish mandatory client requirements from industry practice and vendor implementation guidance. Foundations supplies services, dependencies, people, tools, contracts, approved data locations, operating coverage and delegated decisions. The common architecture remains reusable while those variables determine the next useful step.

The DESMF source available to this research was official-domain indexed text; full PDF retrieval failed. The later DON citation establishes that Edition IV exists, but its full text was inaccessible. Obtain the client's adopted edition and component procedures before asserting conformity. DISA's historical acquisition guide also connects service acquisition to service-specific responsibilities and command/control; it is useful context rather than current delegated authority. (DESMF III, DON edition reference, DISA acquisition guide)

PeopleCert's public material supports a common practice basis without giving this report access to the complete licensed handbook. Avoid describing ITIL 4 as the latest edition or claiming exact Version 5 workflow parity. Use the client's adopted practice and obtain the relevant licensed material when implementation requires it. (PeopleCert transition, Change Enablement, Service Request Management)

Keep cyber response and service restoration connected but separately governed. NIST SP 800-61r3 addresses cybersecurity response across risk management. CISA's 2021 operational playbooks expressly concern Federal Civilian Executive Branch systems; other organizations can benchmark them, but that does not make them DoD command procedures. Current component, CSSP and mission reporting requirements require client verification. (NIST 800-61r3, CISA applicability statement)

The recommendations below are proposed architecture and acceptance requirements. They fit the existing enterprise architecture and operating work, including ITL incident/change/request integration, OPS monitoring and support, DSO controlled delivery, ATO evidence ownership and FIN cost accountability. The existing 30 requests / 51 positions / 10 domains / 53 workstreams remain unchanged. No additional offering, assessment schema or enterprise-repair commitment follows. (Canonical enterprise architecture; catalog source: src/domain-workstreams.js)

One service-management model supports several execution paths

DESMF III's indexed incident guidance emphasizes restoration rather than requiring root cause before service returns. It distinguishes major and security paths and separates request fulfillment. These are useful organizing principles; the client supplies impact thresholds and authority. Our recommended architecture preserves linked records for incident, problem, request and change instead of making one ticket type stand for every decision. (DESMF III, sections 9.4.3 and 9.4.5)

A suspected compromise can constrain an otherwise sensible restoration action. Restarting a server could disrupt evidence collection or containment. The proposed interface therefore links restricted security records by reference, names the security and mission decision owners, and records who resolves conflicts. Ordinary incident ownership does not confer security-response authority, and security tooling does not automatically own service acceptance.

Three-day notice and five-day fulfillment are illustrative planning choices, not universal standards. For example, a client could define an approved routine maintenance pattern that requires notice three working days before its window. The pattern still needs target scope, version, permitted actions, prerequisites, validation, recovery and expiry. Notice demonstrates communication; it does not supply missing approval. If the actual target, dependency state or proposed action differs, the execution leaves the standard path.

Similarly, a catalog request for an additional approved environment might carry an illustrative five-working-day target. The client must specify when that clock starts, what constitutes a complete request, business calendar/timezone, whether approval waits pause it, and how exceptions are communicated. Entitlement, funding, service ownership and data classification remain decisions even if provisioning takes minutes. Neither example is a contractual promise from this handbook.

NIST SP 800-128 recognizes defined preapproved/exempt change types while retaining configuration records and security-impact considerations. Emergency work remains in control scope. This supports a deliberate distinction: authorize a repeatable pattern in advance, then validate each execution against its conditions. A normal change needs its designated assessment and approval; an emergency uses the client's expedited authority and documented follow-up. Urgency alone does not create permission. (NIST publication, Full guide, change-control discussion)

Modern delivery and retained workloads share evidence, not identical mechanics

Pipeline delivery supports frequent validated changes, but retained workloads can also use versioned procedures, scripts, schedulers and automated checks. Google's operational guidance combines governance, configuration management and automation; AWS recommends small reversible changes. These support incremental improvement without requiring wholesale application redesign. They do not prove a particular change is reversible. (Google operational change guidance, AWS small reversible changes)

These paths can coexist within one mission service. A modern front end can depend on a retained database, shared identity or DNS. Azure's deployment guidance explicitly treats stateful/schema recovery as difficult and distinguishes rollback, roll-forward and replacement. Reverting application code is insufficient when stored data changed incompatibly; restoring a backup can discard later writes. The acceptance requirement is a tested recovery strategy with accepted data consequences, not a rollback button. (Azure safe deployment guidance)

Scheduled maintenance is a real automation option for retained systems. AWS Maintenance Windows, for example, supports defined targets, tasks, duration, timezone and activation dates. That demonstrates a capability pattern, not a vendor selection. Existing approved schedulers or orchestration tools should be assessed first. (AWS Maintenance Windows)

Preauthorization can remove repeated human approval for eligible executions while preserving checking and accountability. AWS Change Manager documents preapproved templates and optionally autoapproved requests under policy/calendar controls; it closed to new customers on November 7, 2025, so it is an illustration, not a procurement recommendation here. Possession of CI/CD likewise does not confer production authority. DoD's cATO implementation guidance concerns a particular authorization context; only indexed primary text was accessible in this research, so validate the full current guide and component conditions before applying it. (AWS Change Manager, DoD cATO guide)

DoD examples support bounded automation, with precise evidence limits

It would be inaccurate to say DoD does not automate operations. It would also be inaccurate to treat every provisioning pipeline, security response or container restart as proof of autonomous mission-application recovery. The following evidence supports different conclusions.

The DISA account is the strongest recent operational example found in this bounded search. The official DISA publication was readable; its June 13 DON CIO republication was available through indexed text but rejected direct retrieval. Treat its benefits as agency-reported outcomes, not transferable performance guarantees. (DISA account, DON republication)

ARAD establishes actual historical operational adoption, with security/endpoint scope. The public announcement does not provide its exact execution permissions; a separate 2017 memorandum was inaccessible and supplies no additional obligations here. The Kubernetes design is an architectural reference, while NPS supplies explicit restart/reboot examples in an experimental setting. Its restricted appendix was not accessed. These distinctions matter more than the shared word “automation.” (Air Force ARAD, DoD Kubernetes design, NPS report, printed p.37)

A Cloud One communication describes CIPS self-healing, but its exact publication date, mechanism and authority were not established. Vendor capability statements similarly require deployment verification. Neither should anchor a claim that AI controls mission recovery. Public evidence did not establish the particular example of a production DoD legacy host automatically rebooted every third night. That is an evidence gap, not proof nobody does it. (Cloud One program statement)

Recommend response capabilities through evidence gates and existing investments

Our recommendation is to include optional, narrowly authorized application-response integration in the cloud/GSS reference architecture. Identify the service-owner interface, workflow/policy decision, scoped executor and outcome evidence. This permits future response without expanding the engagement into application performance management or bespoke application repair. Keep monitoring, AI advice, human authority and execution identities distinct. The existing architecture's human-review and controlled execution path remains the baseline; any later standing delegation must be explicitly designed and approved.

Progression applies to an action and service, not an enterprise-wide maturity label. A platform can already replace stateless unhealthy instances while a legacy stateful service remains human-operated. AWS documents unhealthy-instance replacement as a native controller function; Kubernetes documents platform self-healing. Neither requires an AI model, nor proves application correctness. (AWS health checks, Kubernetes self-healing)

The following fictional examples identify design requirements, not executable procedures or authorization.

A proposed three-night reboot interval needs evidence; it is not inherently safe. An undefined “N-minus-three” description does not establish support status, cause or acceptable risk. A reboot cannot generally be undone; the design needs an explicit recovery/fallback path rather than casually promising rollback. Unknown action results must stop duplicate execution until reconciled. The workaround requires an expiry linked to permanent correction, supported replacement or retirement, with review if sunset slips. It cannot waive security, backup, support or retention obligations.

Signal/noise configuration belongs before expanding response. Our recommendation is to map alerts to services and owners, normalize identity/time, distinguish missing telemetry from healthy operation, deduplicate repeat delivery, and test thresholds against mission periods. Record every suppression/grouping rule, reason, owner and review date. Maintenance suppression should be scoped and expire. Measure missed actionable events and incorrect grouping alongside reduced volume. A quieter console can conceal an outage; correlated signals accelerate investigation but do not prove cause.

Acquisition should follow a verified gap in existing capabilities. Configuration and integration can take longer than installation: permissions, routing, identity mapping, source semantics, calendars, evidence retention, supplier boundaries and end-to-end validation all need explicit owners. Separate these blockers instead of calling every delay immaturity.

Our decision rule distinguishes a maturity-only delay from a potential authorization delay. When required control or monitoring evidence is absent and the responsible authority has accepted no interim or compensating arrangement, the gap can delay authorization or approval for the affected activity. This is not a blanket vendor requirement: the actual authorizing official or delegated decision owner determines applicability and acceptance. A manual workaround is acceptable only where evidence and authority support it; describing it as interim does not resolve a control gap or guarantee approval. (NIST SP 800-128)

Carry current, interim and future views: use approved tools and manual evidence now; integrate stable steps where justified; recommend later capabilities with their entry conditions. Rehearse false triggers, intentional stops, stale data, expired authority, concurrent maintenance, unavailable capacity, timeout/unknown result and failed recovery. Evaluate unauthorized-action prevention, correct abstention, audit completeness and verified service outcome as well as restoration speed. AI introduces separate questions of data admission, quality and review burden; it cannot authorize its own output.

“Year three” is a client planning hypothesis, not an industry standard or authorization gate. A client can defer execution automation while retaining the architectural option. The advisory handover should identify requirement, existing capability, gap, option, accountable decision owner, acquisition/integration/configuration dependency and acceptance evidence. That creates an actionable sequence without promising a purchase, deployment date or completed operational service.

Optional prompts refine the reference with client evidence

Use only approved material and approved processing locations. These analysis-only starters help the receiving team adapt the handbook; they do not authorize data upload, configuration changes or execution.

Applicability and handoffs: “Using the supplied adopted policies, service boundary, tools and owner records, map incident, major incident, request and change handoffs. Cite each input. Separate verified requirements, recommendations and unknowns. Identify provider/client and security/service interfaces. Do not invent approval rights, deadlines or completed procedures.”

Bounded response assessment: “Assess this proposed response using the supplied evidence. Identify target/action limits, dependencies, preconditions, authority, recovery, stop rules, expiry and outcome checks. Include intentional-stop, stale-data and unknown-result counterexamples. Recommend observe, advise, human-approved action or consideration for preauthorization, with missing evidence. Produce no executable commands or resource changes.”