Fictional / Illustrative sample — invented organisation, evidence and dates. Not a client engagement.
A fictional sample of the Critical Service Disruption & Cyber Resilience Evidence Report, prepared for an invented company, Fenwick Ridge Components, a mid-sized manufacturer of industrial fittings.
Every name, exhibit and date on this page is invented to show how the report is structured. No real organisation, incident or engagement is described. No live technical testing is represented. Dates are shown relative to a fictional assessment start, “A”.
Fenwick Ridge asked whether it could show what would happen if its order-to-dispatch service were disrupted.
The evidence indicates a service that functions well day to day and has a documented fallback. It also indicates that resilience is understood mainly through the order platform provider, while the service depends on several components outside that agreement.
The organisation cannot currently demonstrate, from the evidence supplied, that orders could be taken, picked and dispatched during a disruption lasting more than a few hours. That is not the same as saying it could not. It means the confidence leadership may hold is not yet supported by evidence.
Most findings concern ownership, demonstration and supplier understanding rather than technical weakness.
Key points for leadership
In scope (as agreed)
Excluded
Fenwick Ridge (fictional) supplies fittings to trade distributors. Orders arrive through a cloud order platform. Staff sign in through a single identity provider. A hosted middleware service passes orders to the warehouse, where pick lists are printed. Parcels are labelled and booked through a logistics provider's API.
Leadership regards order-to-dispatch as its most critical digital service: if it stops, revenue and customer commitments are affected within a working day.
Each exhibit records its source, what it claims, and the limits of what it can establish. Findings reference exhibits by ID.
| Component | Owner | If unavailable | Fallback | Evidence | Status |
|---|---|---|---|---|---|
| Cloud order platform | IT Manager / provider | No new orders recorded | Manual entry (E-03) | E-02, E-03 | Fallback documented, not exercised |
| Identity provider | IT Manager | Staff cannot sign in to order platform or middleware | None documented | E-04 | Gap in evidence |
| Warehouse integration (hosted middleware) | Unclear | Orders do not reach pick lists | Manual pick lists (E-07) | E-06, E-07 | Informal practice only |
| Logistics carrier label API | Commercial Manager | Parcels cannot be labelled or booked | None documented | E-05 | Supplier dependency not assessed |
| Order data exports | IT Manager | Recovery of recent orders uncertain | Nightly export (E-09) | E-09 | Restore not demonstrated |
Scroll the table sideways to see all columns
The scenario is a reasoning aid, not a prediction or a test. It asks what the evidence suggests would happen, and where the evidence runs out.
Assumption: the identity provider is unavailable to staff for one working day, for reasons outside the organisation's control. The order platform itself remains available.
Staff cannot sign in to the order platform or middleware. No documented break-glass route (E-04).
Manual order fallback (E-03) may be invoked, but it assumes the order platform is reachable by staff — which it is not.
Warehouse supervisors would likely revert to improvised pick lists (E-07), without confirmed order data.
Carrier booking depends on access to the label API through the same identity route (E-01). No alternative is documented (E-05).
“We can fall back to manual orders for two days.”
E-03 documents the fallback. No exercise record supplied. E-07 suggests staff improvise rather than follow the plan.
“The cloud provider handles resilience.”
E-02 covers provider infrastructure. Identity, middleware and carrier interface sit outside it (E-01, E-06).
“Backups are in place.”
E-09 shows exports complete. No restore evidenced.
“Admin access is tightly controlled.”
E-04 shows 4 global admins. No access review supplied. Number is not inherently excessive for this size.
“The warehouse change went smoothly.”
E-06 shows no incidents logged. Post-change review not performed; E-01 not updated.
Confidence reflects the strength of supporting evidence, not the severity of the issue.
The organisation's understanding of resilience centres on the order platform provider. Evidence shows the service also depends on identity, hosted middleware and the carrier API, none of which are covered by E-02.
E-03 provides a credible plan. No exercise record exists, and supervisors described a different, improvised practice (E-07). The fallback may work; the evidence does not show that it would.
Since migration (E-06) no named owner appears in the change record, risk register or architecture diagram.
Dispatch relies on the carrier label API on a reasonable endeavours basis (E-05). No alternative booking route is documented. This is a business dependency as much as a technical one.
Exports complete nightly (E-09). Whether they can be restored into a working order process within the 48-hour fallback window has not been shown.
Concerns examined and not supported
Questions the supplied evidence could not answer, for leadership and service owners.
An extract showing the format of a single finding as it would appear in the written report. Contents are fictional.