Emergency response · per incident
When trust is broken,
restore control step by step.
When a system may be compromised, production has failed or a recovery has stalled, we work with your incident lead. We investigate across system boundaries, set intervention priorities and stay through recovery, with every action and decision on the record. Mobilisation within hours can be arranged, subject to availability and authorised access.
How a response runs
Four steps, the same for every incident. An active incident goes straight to the first one, with no assessment beforehand.
Table 1 The four steps of a response, from the first call to the handover.
-
01 / objective
Agree the objective
We start from the affected services, the business impact and the constraints you work under. With the people responsible, we agree the outcome, the scope and the criteria the work is checked against.
-
02 / authority
Agree authority and access
You name a technical lead, the people who decide and the contacts for escalation. Access, change approval, evidence handling and spending authority are agreed before anyone intervenes.
-
03 / record
Keep decisions visible
We work alongside your security, infrastructure and application teams, and your MSP or MSSP if you have one. Actions, findings and decisions are recorded, with updates at the cadence you agree.
-
04 / handover
Validate and hand over
The result is checked against the agreed criteria. Remaining risks, recovery procedures and next actions are written down, each with a clear owner after the engagement.
(i) The decisions stay with the people you name in step 02, and each one goes on the record.
Terms at activation. Scope, spending authority and the next decision point are agreed when the work starts. Response work costs €280 an hour, excluding VAT, with the first eight hours paid when it starts; clients use the hours in their plan, then pay €210 an hour (pricing). Mobilisation starts the response; how long recovery takes depends on the incident.
Containment a person approves
Runtime Assurance, which we built, contains one exact scope at a time: a named person approves it, a deadline ends it, and a journal records it from approval to recovery. We have tested it in an isolated Linux lab.
A draft, then one approval. An operator signs in with a passkey, picks a live connection that netwatch recorded, and chooses a target and a duration. That makes a draft, which changes no rules. The same operator then reviews the exact scope, the evidence and the recovery deadline, and approves them under their own name. The approval works once and lapses within 60 seconds. Once the block is applied, the rule is verified. Ending a block early takes an approval of its own.
A deadline the kernel keeps. A block lasts 300 seconds at most, and a block without an end is refused. The deadline sits in the kernel’s own rule, so traffic comes back by the deadline even if the controller is killed, and a restarted controller never puts an old block back.
No free-form commands. A browser can send choices, such as a connection, a target and a duration, but never command or firewall rule text. Each approved action is written to the journal before it runs, and the journal then records it as pending, active and recovered.
Where it has run. In disposable containers in a lab on two of our machines, where a block covers one user’s traffic to one TCP port and one UDP port inside the container. On your systems, containment goes through the controls already there, such as your EDR or firewalls, under the authority agreed in step 02.
| Run | What it shows | Checks |
|---|---|---|
| Operator workflow | The operator’s path: a draft, a one-use approval, the block, then an early restore with its own approval | 51 |
| Controller killed | Traffic recovers at the deadline when the controller is stopped with SIGKILL during a block | 27 |
| Kernel deadline | The kernel lifts the block at its deadline on its own, and a duration of 0 or over 300 s is refused | 11 |
| Unit tests | Each part of Runtime Assurance on its own | 79 |
Three authorities, kept apart
In Runtime Assurance, the part that looks cannot act. Between seeing and acting, a person decides. Both leave a record.
To look. Evidence about a machine’s startup files and sockets comes from a small probe that only reads. Before it runs, its signature is checked, its file sealed and its privileges dropped; it then runs with no network access, no writes and fixed limits. An unsigned or altered probe is refused.
To act. A control with an exact target and an end, approved by a named person, as in Fig. 1.
To record. Findings and actions are kept with their time, and the containment journal follows each action from approval to recovery. For access, askd keeps a sealed audit ledger: every access event is sealed to an offline auditor’s key before it is written.
Where it has run. The probe has been tested in rootless disposable containers in the same lab, with synthetic traffic and fixture files: 41 of 41 checks on 7 October 2026. More on Runtime Assurance.
Three more pieces, on our own systems
We built these three and run them ourselves. Each covers one part of a response, and each entry says where it runs.
Table 3 What each piece does, and where it runs.
-
01 / connections
netwatch: every connection on record
An eBPF collector records every TCP connection in every network namespace, with the process, the bytes and the duration, and every listening port with who can reach it. It keeps 14 days of history and flags scanners touching five or more ports in a minute, programs on the network running from
/tmpand, after a week of learning, processes connecting out for the first time. It runs on one of our own servers. -
02 / identity
Identity Core: replace a machine, revoke keys
The sign-in we built and run ourselves. One transaction revokes a lost or compromised machine, reserves a fresh identity for its replacement and records the change in the audit log. The replacement starts with no access, each grant is given again by hand, and a revocation is never undone. Recovering an account revokes its old keys and sessions and keeps its permissions. Identity Core replaces only the machine’s identity: a compromised machine needs rebuilding from trusted media before its replacement enrols. Tested in October 2026: machine replacement in a dedicated virtual machine, 52 of 52 checks; account recovery against a disposable sign-in server with virtual keys, 34 of 34. More on Identity Core.
-
03 / access
askd: deny, drain and cut at the relay
Machines dial out to the askd relay, so they keep no inbound port open. At the relay, a live policy denies, drains or cuts access, and every access event is sealed to an offline auditor’s key before it is written, so the relay keeps a record it cannot read itself. In use by its author. More on askd.
Tested, and where. Each time this page says tested, it names the setting: disposable containers in a lab, a disposable sign-in server or a dedicated virtual machine. On your systems, a response uses the tools and the access you authorise in step 02.
Already under attack?
Emergency response within hours, subject to availability and authorised access. Tell us what you know so far; these four points are enough to start.
What to send with the request
- SystemsWhat is affected. The services and systems involved, and the impact on the business so far.
- DeadlineWhen you must decide. The next decision you face, and by when.
- AuthorityWho can authorise. The person who approves access, changes and spending.
- CallbackA number to call. Someone we can reach while the incident lasts.
Leave out credentials and evidence. Keep them out of the form; how evidence is handled is agreed with you before work starts.