What does a disconnected-operations requirement look like in an RFP?

A line such as “the system must work offline” cannot be tested, and every vendor can answer yes. A usable requirement states which functions must keep working, for how long, on which devices, with what security, and what evidence will prove it. Writing it that way also forces the buyer to decide what the operation actually needs, which can be the harder part.

Security control catalogues already have places for this. In NIST SP 800-53 Revision 5, control CP-8, Telecommunications Services, asks an organisation to establish alternate telecommunications services so that defined operations can resume within a defined time when primary telecommunications are unavailable. Its enhancements cover avoiding a single point of failure shared with the primary service and testing the alternate service.

SC-8, Transmission Confidentiality and Integrity, asks for transmitted information to be protected on internal and external networks, and its discussion names mobile devices and radios among the components in scope. Enhancement SC-8(1) asks for cryptographic mechanisms to do it.

These controls leave the values blank as organisation-defined parameters, such as a time period or a testing frequency. The RFP is where you fill them in. NIST SP 800-34, the contingency planning guide, supplies the inputs: a business impact analysis gives each process a maximum tolerable downtime and a recovery time objective, which give you a starting point for how long the system must work disconnected.

Maximum offline duration. Which functions must work with no network, for how long, and how much work accumulates per device in that time. For example: “Field users can create, edit and hand over work orders for [period] with no internet, with up to [number] pending records per device.”

Local authentication and revocation. How users and devices prove who they are with no network, how long a cached credential stays valid, and how revocation reaches devices that are offline. Ask what happens to a user revoked while their device was disconnected.

Encryption on a named standard. Name the standard for device-to-device and group traffic, for example the MLS protocol defined in RFC 9420, an IETF Standards Track specification for group key establishment with forward secrecy and post-compromise security. Ask for a list of every message type that travels unencrypted or only signed.

Delivery semantics and duplicates. What “delivered” means, which delivery guarantee applies, and how the receiving side detects and discards duplicates. Retries after a reconnection can produce them.

Conflict rules. The merge rule for each kind of data edited on several devices while apart, and which conflicts the backend must decide because a business rule has to hold.

Audit trail. Which events are recorded while devices are offline, how the records are protected on the device, and when they reach the central log. Control AU-2, Event Logging, asks an organisation to define the event types it logs and why they are adequate for investigating incidents afterwards; the RFP should say whether that list includes offline actions.

Telemetry and data that never leaves the device. An inventory of what the product collects, whether collection is opt-in, and which fields stay on the device by design.

Supported devices and OS versions. Named device models and minimum OS versions for each platform, mixed-platform pairs, and behaviour when the app is in the background.

Testing evidence on real hardware. Measured results, on the named devices, for the failure cases you care about.

Control CP-4, Contingency Plan Testing, lists methods that range from checklists, walk-throughs and tabletop exercises to simulations, run in parallel or as a full interrupt, and comprehensive exercises. For disconnected operations, paper evidence is not enough. Ask for results from physical devices: internet off while devices keep working, devices separated and reconnected, the app killed with work pending, queues filled, duplicate operations, and the backend down and then recovered. The guide to testing offline behaviour describes these cases, and evaluating an offline SDK covers the questions to ask alongside them.

Ask for results with the date, device models, OS versions and software version recorded, and treat a simulator result as evidence of integration only.

• Give the scenario. Describe the site, the devices, the length of a typical disconnection, and the workload.
• Ask for documented limits. Defaults and configurable values, with the version they apply to.
• Use a compliance matrix. For each requirement: meets, partly meets, or does not meet, with an explanation and a reference to documentation.
• Ask for the deployment record. Vendor documentation can help here. Offline Protocol’s production guide, for example, asks each deployment to record its SDK version, device models, OS versions, transports, topology, enrolment policy and expected workload, and to define retention, maximum offline duration, queue capacity and acceptance rules. A vendor that keeps a record like that can answer most of the categories above directly.