Security boundary: if an active breach is suspected, preserve evidence and use a qualified incident-response team for containment. The sequence below is an application-recovery plan, not a substitute for cyber incident response.
Hours 0-2: establish authority
- Name one business incident owner and one technical change approver.
- Confirm legal ownership of the domain, cloud account, Adobe licenses, repositories, accounts, and business data.
- Stop credential sharing. Record who has current access and begin approved rotation where needed.
- Pause risky releases and document any emergency change already in progress.
Hours 2-8: preserve a reliable baseline
- Take and verify backups for code, configuration, databases, media, and infrastructure definitions.
- Preserve application, web server, queue, payment, middleware, ERP, CDN, WAF, and deployment logs.
- Record current error rates, checkout completion, order creation, ERP handoff, stock, price, and payment states.
- Capture the active release version, extensions, Composer lock, environment variables, cron schedules, and queue consumers.
Hours 8-24: protect the money path
- Build a list of affected order IDs and compare commerce, payment, middleware, and ERP records.
- Stop blind retries that can create duplicate orders, charges, or stock movements.
- Define a manual reconciliation and customer-service process for orders that cannot safely move automatically.
- Write rollback triggers and validation steps for any production fix that cannot wait.
Hours 24-48: prepare diagnosis
Give the takeover team read access first. The audit should separate code defects from data, hosting, release, integration, ownership, and product-scope failures. Require every finding to include evidence, business impact, immediate containment, proposed fix, dependency, and validation method.
| Track | Evidence | Decision |
|---|---|---|
| Checkout and payment | Error traces, gateway state, totals, redirects, webhooks, duplicate controls | Can trading continue safely? |
| Orders and ERP | Stable IDs, queues, retries, mappings, dead letters, reconciliation | Can records be replayed without duplication? |
| Release and infrastructure | Pipeline, environments, configuration drift, rollback, monitoring | Can the team make a controlled production change? |
| Code and extensions | Repository history, dependencies, custom modules, tests, unsupported packages | Repair, refactor, rebuild, or replace? |
Hours 48-72: agree the first controlled move
- Approve one prioritized recovery backlog with explicit acceptance tests.
- Separate containment, stabilization, root-cause repair, and later improvement.
- Name the release owner, validation owner, rollback authority, and business sign-off.
- Agree what evidence would stop implementation and trigger a rebuild or replatform decision.
- Set daily communication hours and escalation rules for the proposed team. Do not infer 24/7 coverage.
A disciplined first 72 hours may produce no visible feature work. That is acceptable when it prevents evidence loss, duplicate orders, unsafe access, or a second failed takeover.
Continue the takeover review
Use the full access checklist, compare rescue versus rebuild, read the RESTORE-100 method, or return to the eight ranked rescue agencies.