Incident Response Reserve
When your enterprise is compromised, the response should not depend on it.
A serious incident can put the systems you would normally coordinate through inside the boundary of what is being investigated. The Incident Response Reserve is designed as a communication and authority environment established before that day, held outside the enterprise's trust dependency, intended to be exercised so it is known to work, and activated when the ordinary systems can no longer be assumed sound.
- Pre-positioned
- Independently governed
- Exercised, not assumed
- Available under controlled evaluation
01 · The failure
The response runs on the systems the response is about.
During a serious compromise an organization may have to question the integrity of the very systems it uses to coordinate. Not because they are known to be compromised, but because they sit inside the incident's trust boundary and cannot be assumed sound until they have been examined.
- Corporate email, where the response would ordinarily be organized.
- Enterprise messaging and internal collaboration systems.
- Identity infrastructure, which decides who any of those systems believe you are.
- Managed endpoints, administered by the same estate under examination.
- VPN and remote access paths into the environment.
- Administrative consoles, which are what an adversary wants most.
The system investigating the incident should not have to trust the system under investigation.
None of this asserts that any of those systems is compromised in a given incident. The operational problem is narrower and harder: at the moment a response begins, you usually cannot yet say which of them is sound, and the response cannot wait for that answer.
02 · The reserve
A response environment that already exists when you need it.
The reserve is not a second messenger switched on under pressure. It is authority, identity and equipment arranged in advance, so that on the day of an incident the question is who is authorized rather than what can we still use.
- Responders authorized before the incident, not enrolled during it.
- Endpoints provisioned and separately trusted for response use.
- Administrative authority for the reserve, held apart from ordinary operations.
- Incident-specific mission identities, scoped to the response.
- Relationships and capability grants defined ahead of time.
- Authority that is time-bounded, so nothing is granted indefinitely.
- Alternative transport paths for when ordinary connectivity is unavailable.
- Governance receipts, so the response leaves a record it can stand behind.
03 · Lifecycle
Provisioned, exercised, maintained, long before it is activated.
A reserve that has never been used with the actual people and the actual equipment is a plan rather than a capability. The stages before an incident are what decide whether the stages during one are available at all.
- Provision
- Establish the authority, the responders, the devices and the reserve environment while nothing is wrong.
- Exercise
- Test that the reserve works with the people and equipment expected to use it. An untested reserve is an assumption.
- Maintain
- Keep authority, devices, credentials and deployment state current, so the reserve does not quietly expire.
- Activate
- Move response coordination into the reserve when the normal trust domain cannot be relied upon.
- Contain
- Change relationships, capabilities and authority as the incident develops and what you know changes.
- Recover
- Coordinate restoration while the governance record and the evidence remain intact.
- Standby
- Return the reserve to a controlled ready state, maintained for the next time.
05 · Containment
Authority changes as the response changes.
What you believe at hour two is not what you believe at hour forty. Authority is administered during the incident rather than fixed at the start of it.
- Withdraw a responder from the response entirely.
- Remove file exchange from a relationship while leaving messaging in place.
- End a single relationship without disturbing the rest of the response.
- Let an authority lease expire rather than renewing it.
- Freeze a mission, which stops operations on the device with no network needed.
- Apply a scoped kill: a device, a mission, a relationship or a single capability.
- Require multiple officers for the highest-impact withdrawals.
- Block protected material from being unlocked under a duress condition.
06 · Transport independence
Response coordination should survive the network changing under it.
Communication is carried as a Secure Mission Bundle: a transport-independent sealed package carrying its own authorization and expiry. Connected and disconnected paths are delivery mechanisms, and neither becomes the root of trust.
The transport may change. The authority does not.
A bundle can move over a relay, over satellite or radio carriage, or by a disconnected transfer on removable media, NFC or a QR code. The receiving endpoint still evaluates the applicable device, mission, relationship, capability and time-bound authority before the material can be used. The full architecture is set out on Capabilities.
07 · Failure-domain independence
Separation has to be designed. It is not a side effect of installation.
A reserve is only independent to the degree the deployment makes it independent. This is the section to read closely, because it is the one an assessor will.
- Administrative authority for the reserve, separate from ordinary IT administration.
- Devices provisioned for response use rather than drawn from the managed estate.
- Credentials that do not derive from the identity infrastructure under examination.
- A separate security domain, to the extent the deployment model supports it.
- Connectivity that does not depend on the same path as ordinary operations.
- Deployment infrastructure held apart from the environment being investigated.
- Responder identities established in advance, not created during the incident.
- Disconnected procedures for when none of the above is available.
08 · External responders
Bring people in without giving them the organization.
A serious response involves people who are not employees: an incident-response firm, outside counsel, forensics specialists, critical vendors. Each needs to reach specific people for a specific period, and nothing beyond that.
- Mission-scoped authority
- An external responder is authorized inside the incident mission, not admitted to the organization's general directory.
- Directional relationships
- A grant that authorizes a specialist to reach the forensics lead does not authorize the reverse, and does not authorize anyone else.
- Capability by capability
- File exchange is granted separately from messaging. Being able to send a message is not being able to send a file.
- Time-bounded
- Authority carries a validity window set when it is issued, so access ends without anyone having to remember to remove it.
- Withdrawable
- Authority can be withdrawn during the incident at the scope that fits: one relationship, one capability, one device.
This is relationship-protected networking applied to the case it was designed for. Adding a responder is an authorization decision with a scope and an end date, rather than an invitation to a workspace that someone will need to remember to revoke.
09 · Governance without reading the messages
An account of what was authorized, not a copy of what was said.
A response has to be defensible afterwards. Command records the authority decisions it makes, in a tamper-evident chain, and holds no key that can decrypt the content it authorized.
- Authority issued, and to whom.
- Authority withdrawn, at which scope.
- A relationship established or ended.
- A capability granted or removed.
- A bundle accepted or refused, and the reason it was refused.
- A mission frozen, and when.
- A control action applied on an endpoint.
Command governs what is authorized, not what was said. Administration and content are separate surfaces, and the administrative one holds no content key.
10 · Assurance state
What is proven, and what is not yet.
The same three lines that appear on Assurance, rendered from the same source. This page previously summarized the evidence in its own words and reached a different answer to the same question, which is a worse defect than either wording.
- Device Authority: physically verified, on Android, one handset model
- A device identity is a P-256 key generated in the Android Keystore, non-exportable, hardware-backed where the platform allows, with attestation-chain verification. Bind, reconnect, reboot, rotate, revoke and post-revoke refusal were demonstrated on real hardware. The scope is one handset model, which makes it a demonstration rather than a device compatibility matrix. iOS and macOS carry their own evidence state, which Assurance sets out platform by platform.
- Human Authority: physically verified, at Command
- An operator authenticating with a physical hardware security key, producing a Command session that carries an authority role and is recorded in a verifying audit chain. It proves the operator step, and only that step. The device key, the organization root and every payload key sit outside its scope, as does any endpoint capability.
- Physical acceptance of the application path: outstanding
- Two-endpoint acceptance of the application path remains outstanding on every platform, reboot persistence awaits physical execution, and the duress gesture and its canary delivery are pending. This class of evidence is tracked separately from automated and controlled-environment verification, and it is not claimed until it exists. Independent external assessment remains open for every property on this page.
- The reserve, specifically
- The authority model and the containment primitives behind the reserve, meaning scoped withdrawal by device, mission, relationship and capability; multi-officer authorization for the highest-impact withdrawals; mission freeze and lease expiry; duress blocking; and a tamper-evident governance chain that survives restart, are asserted by deterministic adversarial tests. Live disconnected containment and a two-endpoint call with people in the loop are part of the outstanding physical acceptance above.
- Operational deployment: none claimed
- No production incident activation, customer deployment or operational proving is represented. The reserve is available under controlled evaluation.
See Assurance for the current scope-specific evidence register.
11 · Who this is for
Organizations whose response cannot pause while trust is re-established.
- Enterprise security functions with a defined incident-response mandate.
- Critical infrastructure operators.
- The defense industrial base.
- Incident-response teams, internal and retained.
- Executive crisis coordination.
Next step
Plan an Incident Response Reserve.
A working session with an engineer: your trust dependencies, what a separate failure domain would mean in your environment, and what would have to be provisioned and exercised before it could be relied upon.