Business Continuity Management

BC.PR.01 · Policy & Procedure · Ethereum Staking Operations

Author: Colin Lewis · June 2026

Document Information

​

Document History

Contents

Document Information 2

Document History 2

Contents 5

1. Management Commitment 7

2. Purpose 8

3. Scope 9

4. Definitions 10

5. Roles and Responsibilities 12

6. Continuity Philosophy — Safety First 13

7. Automated Anti-Slashing Controls 14

7.1 Signing Integrity and Durable Slashing-Protection State 14

7.2 Threshold Signing Architecture (DIRK 3-of-5) 14

7.3 Vouch Operation 14

7.4 Emergency Shut-Down (ESD) Daemon 14

7.5 Client Diversity — Consensus and Execution 15

7.6 Validator Key Protection and Key-Shard Lifecycle 15

7.7 Secure Development and Build Integrity 17

7.8 Planned Maintenance and Rolling Upgrades 17

8. Recovery Objectives 18

9. BCP Trigger Criteria 20

10. Business Impact Analysis 22

10.1 Slashing 22

10.2 Inactivity / Downtime 22

10.3 Monitoring Degradation 22

10.4 Corporate System Outage 22

11. Infrastructure Resilience 23

11.1 Multi-Vendor, Multi-Jurisdiction Model 23

11.2 Bare-Metal Control 23

11.3 Access Control 23

11.4 Backup and Durable State 23

11.5 Beacon and Execution Nodes 24

11.6 Cloud Services 24

12. Third-Party Dependencies and Supplier Management 25

13. Communication and Escalation 26

13.1 Internal Escalation 26

13.2 Client Notification 26

13.3 Incident Logging and Evidence 26

14. Emergency Action Process 27

15. Testing and Review 28

15.1 Annual Testing 28

15.2 Test Documentation 28

15.3 Policy Review 29

15.4 Continuity Objectives and Metrics 29

Appendix A. Anti-Slashing Failover Checklist 30

Appendix B. ISO/IEC 27001:2022 Control Mapping 32

1. Management Commitment

Attestant is committed to maintaining continuous, secure and resilient Ethereum validator operations for its clients. The protection of client staked assets is the primary continuity objective of this organisation. Senior management recognises that business continuity within Ethereum staking requires a materially different philosophy to conventional IT continuity — one in which the prevention of protocol-level events, such as slashing penalties, takes precedence over the restoration of uptime.

This policy has been reviewed and approved by the named approver below and forms a binding component of Attestant’s ISO/IEC 27001 Information Security Management System (ISMS). Compliance is mandatory for all personnel with access to, or responsibility for, Attestant’s staking infrastructure or corporate systems.

Document Owner: Chief Risk Officer (CRO). Approved By: Numaan Ahmed, CRO. Date: 25/06/2026.

Out-of-cycle reviews shall be triggered by: any material change to the Ethereum consensus protocol; changes to the DIRK or Vouch architecture; addition or removal of a hosting provider; a significant security incident; or any triggered BCP event. The policy is reviewed at minimum annually given the importance senior management places on the resilience of its staking operations for clients.

2. Purpose

The purpose of this policy and procedure is to establish the framework by which Attestant maintains business continuity across its Ethereum staking operations. As a professional staking provider, Attestant’s primary continuity objective is the protection of validator integrity and client assets.

In brief — for non-specialist readers. Attestant runs Ethereum validators on behalf of its clients. A validator is an identity on the Ethereum network that uses a cryptographic signing key to routinely sign small messages — attestations (votes on the state of the chain) and, occasionally, proposed blocks; doing this correctly and on time earns rewards for the client. The single most serious risk is slashing: a protocol penalty for signing two conflicting messages, which is irreversible — so this policy treats avoiding it as more important than maximising uptime. Attestant’s design splits each signing key across several machines so that no one machine can sign alone, and separates the software that decides what to sign (Vouch) from the machines that hold the key shares and actually sign (the DIRK signers). The sections that follow describe how that design keeps validators running safely, and what happens when something fails.

Unlike traditional IT environments where uptime alone is the overriding concern, continuity within Ethereum staking must balance availability with the prevention of protocol-level penalties such as slashing. This document defines how Attestant ensures validator operations continue in a secure, controlled and resilient manner during infrastructure failures, vendor outages, protocol events or other emergencies, while meeting its contractual and regulatory obligations.

Obligations driving these objectives. Attestant’s continuity obligations arise from (a) client contractual commitments — including service-availability expectations and the allocation of liability for slashing losses — maintained in the client agreement register; and (b) applicable legal and regulatory requirements, maintained in the ISMS legal and regulatory register (A.5.31). Attestant is not currently authorised as a financial-services firm and is not yet required to be; its binding statutory obligations today are in data protection — the UK GDPR and the Data Protection Act 2018, regulated by the Information Commissioner’s Office (ICO) — under which the one externally-mandated reporting timeline is the ICO personal-data-breach notification, within 72 hours of awareness where the UK GDPR risk threshold is met. The UK is, however, bringing cryptoasset activities — staking included — within the Financial Services and Markets Act perimeter under the FSMA (Cryptoassets) Regulations 2026, with the FCA authorisation gateway opening in 2026 and the regime expected to take full effect in late 2027; Attestant anticipates that its institutional staking services will fall within scope, treats this as a formal review trigger (Section 15.3), and is preparing on the basis that its existing ISO 27001 ISMS — the governance, operational-resilience and key-management controls in this policy — already aligns with much of what the FCA is signalling. Recovery objectives (Section 8) and client-notification timelines (Section 13) are contractual and derive from these obligations and the Business Impact Analysis (Section 10), rather than being set arbitrarily.

This policy forms part of Attestant’s ISO/IEC 27001:2022 ISMS. It maps primarily to Annex A controls A.5.29, A.5.30, A.5.19–A.5.22, A.8.8, A.8.13, A.8.14 and A.8.25, with the full control mapping set out in Appendix B.

3. Scope

This policy applies to all Attestant information systems and operations, which fall into two domains:

Corporate Operations. Administrative systems including Google Workspace, internal communications platforms and documentation repositories. These support business functions but are not directly involved in validator signing operations.

Staking Infrastructure. All production and development validator infrastructure, including bare-metal servers, DIRK distributed signing nodes, Vouch validator clients, beacon and execution nodes, monitoring and alerting systems, and associated configuration-management systems. Attestant does not operate its own physical data centres; all infrastructure is deployed across multiple independent third-party bare-metal hosting providers, distributed across multiple geographic locations and jurisdictions to maximise resilience and reduce provider-concentration risk.

The following operating-model characteristics are material to this policy:

• All servers are bare-metal with Attestant’s own hardened build; no third-party managed cloud services or shared compute environments are used for validator operations.

• The staking infrastructure is segregated into Pods. A pod typically comprises seven servers: two Vouch validator servers (a primary and a standby), each running the Vouch client together with multiple consensus and execution clients and holding everything required for attestation except signing; and five DIRK signer nodes. Off-the-shelf consensus and execution clients (for example Teku, Geth, Lighthouse) ship with built-in signing; Attestant disables that and deliberately separates signing onto the dedicated DIRK signers, which is what enables the 3-of-5 threshold model and its added security and resilience. The five signers in a pod are termed stripes (stripe 1 to stripe 5). Validator keys are distributed across many pods to provide additional resilience for clients.

• No software other than the authorised Attestant build is permitted on any validator server. That build is produced and verified through the controlled secure-development and build-integrity process in Section 7.7.

• Access to all infrastructure requires multi-factor authentication: authorised SSH public keys provisioned in advance; encrypted SSH authentication with a minimum 16-character passphrase; and FIDO2 hardware security keys.

• No individual has access to the entirety of the validator fleet. Access is deliberately partitioned to prevent single-point compromise, internal or external.

• Amazon Route 53 (AWS) is used for DNS only — the sole use of any hyperscaler managed service — with access tightly restricted to senior managers (see Sections 11.2 and 11.6).

4. Definitions

Emergency: Any unpredictable event — infrastructure failure, vendor outage, protocol vulnerability, network partition or security incident — that prevents normal validator operation or introduces material slashing risk.

Validator: An identity on the Ethereum network, activated by staked ETH, that earns rewards for its operator’s client by correctly performing signing duties — attesting and, when selected, proposing blocks. A validator is operated through software and a signing key; it is not a person.

Attestation: The routine vote a validator signs in each epoch on what it sees as the current head of the chain. Attesting correctly and on time earns rewards; signing two conflicting attestations is a slashable offence.

Slashing: A protocol-enforced penalty resulting in the permanent loss of a portion of staked ETH and forced exit of the affected validator from the Ethereum network.

DIRK (Distributed Remote Keymanager): Attestant's internally developed remote key-management and threshold-signing system, kept separate from the validator client so that those who operate the validator client hold no signing keys. A quorum of DIRK nodes (3 of 5) must participate to produce a valid signature; no single node can sign independently.

Vouch: Attestant’s internally developed multi-node validator client. Vouch coordinates signing requests to the DIRK clusters and maintains a standby instance within each Pod and a dedicated BCP instance outside the pod for extreme scenarios.

Beacon node: Software that runs a full copy of Ethereum’s consensus (proof-of-stake) layer. Vouch relies on beacon nodes to learn the current chain state and a validator’s upcoming duties; Attestant runs several, on different client implementations, for diversity and redundancy.

Execution node: Software that runs Ethereum’s execution layer — transactions and account state — paired with a beacon node. Attestant runs several execution clients for the same diversity and redundancy reasons.

Pod: A self-contained unit of Attestant’s staking infrastructure — typically seven servers: two Vouch validator servers (a primary and a standby) and five DIRK signer nodes (stripes 1 to 5). Validator keys are distributed across many pods, and a pod’s five signers operate the 3-of-5 threshold-signing quorum.

Stripe: Within a pod, each of the five DIRK signer nodes is a stripe (stripe 1 to stripe 5). Each stripe has a primary owner and a backup owner who hold its access credentials and the associated validator-key shard.

Critical Processes: Activities mandatory to prevent financial loss or protocol penalties: validator uptime, secure threshold signing, slashing-protection integrity and monitoring.

Slashing-Protection Data (EIP-3076): The record of a validator key’s prior signing history (highest signed attestation source/target epochs and block slots), held in the standardised EIP-3076 interchange format. Used to prevent a signer from producing a conflicting signature when it is restarted, rebuilt, migrated or promoted.

Inactivity (offline) penalty: The ordinary penalty for missing attestations while a validator is offline. It is broadly equal to the rewards foregone and is recovered over an equivalent period of uptime; it does not cause forced exit.

Inactivity Leak: A distinct protocol mechanism that activates only during network-wide non-finality (when the beacon chain fails to finalise for roughly four or more epochs, typically because over one third of all validators are offline). It is not triggered by an isolated outage of Attestant’s own validators.

Slot: A roughly 12-second interval in which a single block may be proposed; 32 slots make one epoch. Signing histories and slashing-protection checks are keyed to specific slots.

Epoch: A unit of beacon-chain time of 32 slots of ~12 seconds — approximately 6.4 minutes.

RTO / RPO: Recovery Time Objective — the target time to restore a service after disruption. Recovery Point Objective — the maximum acceptable loss of state, measured as a point in time before the disruption.

MTD: Maximum Tolerable Downtime — the outer time boundary beyond which the impact of disruption becomes unacceptable.

UAT: User Acceptance Testing — Attestant’s pre-production environment in which client and configuration changes are validated before deployment.

5. Roles and Responsibilities

BCM responsibilities are role-based; real names are maintained in the Attestant HR and access-control systems.

Delegation and succession of authority. Either the CRO or the COO may authorise any action requiring senior authorisation under this policy; where both are available, the CRO leads. If both the CRO and COO are unreachable within 30 minutes of a trigger, the Lead Engineer together with one other senior manager (a key-shard holder) are jointly authorised to approve restoration in accordance with the Safety-First philosophy, with the decision and rationale logged and reviewed by the CRO at the earliest opportunity. This ensures the plan is never blocked by the unavailability of a single individual. Deputy authorisers apply the same failover checklist and Safety-First decision test as the CRO/COO, and their competence to do so is maintained under the ISMS.

Monitoring and on-call coverage. Monitoring and alerting operate continuously. A 24/7 on-call rota ensures at least two suitably authorised engineers are available at any time; in line with Section 5 these engineers are geographically separated (for example one remote and one in the office) so that a single regional disruption cannot impair both responders. Out-of-hours alerts escalate to the on-call engineer and, for any trigger condition, to the CRO/COO via the incident contact register. Because corporate functions are cloud-based (Google Workspace), all staff retain remote access if the office is unavailable.

6. Continuity Philosophy — Safety First

Attestant’s approach is grounded in a single principle: the prevention of slashing takes precedence over the immediate restoration of validator uptime. The Ethereum protocol imposes irreversible, financially significant penalties for double-signing — submitting two valid but conflicting attestations or block proposals for the same slot. These penalties cannot be reversed, appealed or mitigated after the fact.

In any failure scenario where the current signing state of one or more validators cannot be verified with certainty — for example following an unexpected node restart, a network partition or a failover — the safe course of action is controlled downtime. A validator that is offline accrues modest, recoverable offline penalties; a validator that double-signs is slashed.

Accordingly, the CRO or COO may approve intentional temporary downtime for any portion of the validator fleet when signing state cannot be verified. No engineer may restore signing under ambiguous conditions without CRO or COO authorisation (or, where both are unavailable, the deputy authorisation defined in Section 5).

7. Automated Anti-Slashing Controls

Business continuity is reinforced through deterministic hardware and software controls designed to prevent double-signing under all normal and tested failure conditions. These controls operate independently of human intervention.

7.1 Signing Integrity and Durable Slashing-Protection State

Before producing any signature, every DIRK signer runs the request through a slashing-protection check: it compares the proposed operation against the validator's recorded signing history and refuses to sign anything that could cause a slashing event — a second block proposal for a slot already signed, or a double or surrounding attestation — regardless of the source of the instruction. This is a slashing-condition check, not merely a check for duplicate requests.

The signing history that underpins this check is written to durable, encrypted storage after every signature, in the standardised EIP-3076 format, so that it survives a restart, crash or rebuild; an in-memory copy is kept only to keep the pre-sign check fast. This durable record — not volatile memory — is the authoritative source of truth whenever a signer is restarted, rebuilt, migrated or promoted, and is the basis for the Recovery Point Objectives in Section 8. The control operates at the cryptographic layer and is not bypassable by ordinary operational error.

7.2 Threshold Signing Architecture (DIRK 3-of-5)

Signing operates on a threshold model: at least 3 of 5 DIRK nodes must independently co-sign a request before a valid signature is produced. Therefore:

• Loss of one node has no effect on signing.

• Loss of up to two nodes is tolerated — a quorum of three remains and signing continues uninterrupted.

• No single compromised node can produce a valid signature.

• Loss of three or more nodes simultaneously causes signing to cease — a safe failure mode — rather than degraded or incorrect signing.

DIRK nodes are distributed across multiple hosting providers and geographic locations to minimise the likelihood of correlated failure.

7.3 Vouch Operation

The Vouch validator client attests to the network only when the 3-of-5 DIRK quorum is achieved. If conflicting or anomalous data is detected in the signing responses from the DIRK cluster, Vouch will not attest.

7.4 Emergency Shut-Down (ESD) Daemon

In a worst-case scenario where any validators in a pod are slashed — most likely from a double-signing event — the Emergency Shut-Down (ESD) process detects the slashing and triggers an automatic shutdown to prevent any further slashing within the pod. ESD subscribes to the beacon node’s head-event stream (via the standard beacon API) and inspects each new head block for attester or proposer slashings; on finding one it checks whether the slashed validator is one of Attestant’s own and, if so, runs a pre-defined response script. Detection is event-driven and near-real-time — within a slot of the slashing being included on-chain — so ESD bounds any further slashing rather than the initial event. The response script immediately stops the Vouch validator client and raises a priority on-call alert. Only one Vouch instance is ever active for a pod at any time: the primary, the in-pod standby and a dedicated out-of-pod BCP instance are provisioned identically — ESD included — but the standby and BCP are held stopped and disabled until an operator deliberately activates one. Activation is a controlled, per-pod step that points the chosen Vouch at that pod’s signers and, in the same action, stops any other Vouch for the pod, so two instances can never sign for one pod at once. After an ESD shutdown none may resume: automated restart is never permitted, and re-activation requires the CRO or COO to authorise restoration once root-cause analysis is complete. This forces senior management to fully understand the nature of the event and the controls implemented to ensure it cannot recur before any validator returns to service.

7.5 Client Diversity — Consensus and Execution

Reliance on a single client implementation is a systemic risk to the Ethereum network and to Attestant clients specifically: a critical vulnerability in a client in use could cause mass slashing across affected validators. Attestant therefore runs an active client-diversity strategy across multiple consensus client implementations (currently Prysm, Teku, Lighthouse and Nimbus) and multiple execution client implementations (such as Geth, Nethermind, Besu, Erigon and Reth), configured through Vouch.

Attestant’s diversity strategy ensures that Vouch never attests to the chain on the strength of a single client’s view alone. Vouch is configured with a majority attestation-data strategy: it requests the attestation data from the four independent consensus clients and will only attest when at least two of them agree, so Attestant never lends its attestation weight to a single client’s unverified view. Block proposals likewise draw on all available clients, taking the best valid proposal. This protects both client rewards and the broader network against a single client’s consensus fault.

Threat-intelligence sourcing. Timely detection of a client vulnerability depends on intelligence. Attestant monitors client release and security channels, the Ethereum security disclosure lists, and relevant CVE feeds (A.5.7); the Lead Engineer owns this monitoring and initiates Trigger 4 where required.

On identification of a critical vulnerability in a client in active use, the BCP trigger requires: immediate suspension of the affected client in the Vouch configuration across all validators (or, where appropriate and after UAT testing, immediate application of a vendor fix); emergency migration of affected validators to a pre-tested alternative implementation by updating the Vouch configuration across all pods; and post-migration verification of slashing-protection data, validated in UAT, before attestations resume.

7.6 Validator Key Protection and Key-Shard Lifecycle

Validator signing keys are secured exclusively through DIRK’s threshold-signing architecture. Keys are never stored in plaintext backups, never written to disk unencrypted, and never held in a centralised location. Continuity is achieved through quorum resilience: while a sufficient number of DIRK nodes remain operational, signing continues.

Validator keys cannot move funds. A validator (signing) key can only attest and propose; it has no power to move staked ETH. The withdrawal keys that control the movement of funds are held by clients, not by Attestant. Consequently, even a total compromise of Attestant's signing infrastructure could cause slashing or downtime, but could never transfer or steal client funds.

• Validator keys are generated by a distributed key-generation (DKG) ceremony, initiated by the ethdo tool from an operations server — which contacts the signers to start the process but never holds the key or any shard. The five signers then run the DKG among themselves, each independently deriving and keeping its own shard; the full key is never built on one machine and divided, and never exists in any single place — including the initiating tool — even at creation. The signers communicate only during generation (and any later re-share); in normal signing operation they do not communicate with one another, each responding independently to Vouch. DKG is run in bulk and in advance, and has been performed only twice in Attestant’s history, to minimise opportunities for key compromise. This deliberately avoids the model used by Shamir secret sharing — in which the full private key must be present so that a trusted party can split it — and the rationale is recorded in Attestant’s 2022 R&D submission, which states that distributed key generation was adopted specifically to gain threshold resilience “without the drawback of relying on a trusted party to create the shares.”

• Each pod's validator key exists only as the threshold shards produced by that DKG ceremony — one per signer (stripe) — distributed across the stripe owners; the key is never held whole on any machine. Every stripe has a primary and a backup owner, and no single person holds enough shards to reach the 3-of-5 signing threshold.

• Shard custody. Validator-key shards must never reside on a person's laptop/MacBook. Each shard is held offline on an externally-encrypted SSD, with the passwords needed to mount and decrypt the device kept in the holder's Apple Keychain. Each holder keeps two copies of their shard SSD — a primary and a backup — stored at separate physical locations.

• Hardware keys. Each key-holder has a primary and a backup FIDO2 hardware key; the two hold different private keys, and both corresponding public keys are registered on the signer, so either key can authenticate the holder.

• Separation of stripe ownership. No individual may have access to more than two of a pod's five stripes. Because a backup owner holds the same access to a signer as the primary owner, what matters is the number of stripes a person can reach — not the primary/backup label: capping each individual at two stripes keeps everyone below the three-stripe count that would reach the 3-of-5 signing quorum, so no single person can ever assemble enough access to sign alone. This segregation has applied since the system was formed. Adherence to the two-stripe limit is verified through the quarterly access review (Section 11.3), which cross-matches the SSH public keys deployed on each signer against the authorised stripe-ownership matrix held in the change-controlled Ansible configuration, together with the Key Shard Custody Register — maintained by the Information Security Committee, with a working copy derived from it in the operational Server Info register used by the operations team — which records each stripe’s primary and backup SSH-key and validator-shard holders. Access to the register is on a need-to-know basis; knowing a holder’s identity confers no access to a signer, which additionally requires that holder’s SSH key and FIDO2 device.

• Operational access (“bringing in keys”). When work is required on one or more signers, the relevant stripe owners physically bring in their encrypted shard SSDs together with their FIDO2 hardware keys; signer access is otherwise not possible.

• No single employee holds or can access the threshold number of DIRK nodes within a pod required to cause an internal slashing event.

• Access to the DIRK signer nodes requires multi-factor authentication with FIDO2 hardware security keys, and is restricted to the signer key-holders.

• Signer provisioning and lock-down. New signer hardware is provisioned and built by the operations / SA team using root credentials supplied by the hosting provider, including any low-level configuration (for example BIOS or RAID settings) that the build scripts cannot yet fully generalise. The final build step runs Attestant’s Ansible scripts, which install the DIRK and internal monitoring software, remove all root passwords, and install only the authorised SSH public keys. A signer key-holder then logs on and runs a supplied verification script that confirms all root access has been removed and that the installed public-key list exactly matches the Ansible vault — the formal hand-over to locked-down operation.

• Live-signer access and changes. From that hand-over the signer is accessible only to key-holders (an authorised SSH private key together with a FIDO2 hardware key) — the operations / SA team can no longer log on. Changes to a live signer are rare and are carried out by a key-holder running a pre-tested, reviewed script under SA supervision (four-eyes); the SA directs the change but has no access to the box.

Rebuilding a DIRK signer — slashing-protection handling. When a replacement DIRK signer is created for an existing validator key, it does not start from a blank history. Its slashing-protection state is re-established and its integrity verified before the signer is permitted to sign. Because the 3-of-5 distribution tolerates the loss of one or two signers with no loss of history, in the usual case the authoritative EIP-3076 record retained within the surviving pod is imported; the import is performed only while the signer is stopped, and the slashing-protection store never regresses — an imported record older than the existing protection is rejected, so the state can only tighten, never weaken. As a further safeguard — and the sole safeguard in the rare event that an entire pod is lost and no prior record survives — the replacement node observes the chain for a minimum of five epochs (~32 minutes) so that any signature not present in its record is seen on-chain before the node is added to DNS and made visible to the Vouch instances in the pod. Together these steps prevent a rebuilt signer from signing a slot for which a conflicting signature may already exist, and they rely on the surviving quorum’s durable on-disk state and on-chain reconciliation rather than any off-box backup of the signing store. Rebuilding requires the 3-of-5 senior-manager shards and follows the same provisioning and lock-down sequence: the operations / SA team provision and lock down the replacement hardware, and the senior-manager shard-holders then complete the DIRK re-initialisation and key-holder verification, after which the SA team has no access to the live signer.

Shard-holder lifecycle. The custody of key shards is managed across its lifecycle: shards are issued on appointment of an authorised senior manager and securely revoked or rotated on departure, role change, suspected compromise or loss of a shard. Any such event triggers a documented assessment of whether a re-share or fresh DKG ceremony is required to maintain the 3-of-5 threshold. Each shard is held under defined secure storage, and a tested recovery path exists for the loss of any single shard. The leaver/joiner process is cross-referenced to the HR and access-control procedures (A.6.5).

7.7 Secure Development and Build Integrity

Because the authorised Attestant build and the in-house DIRK and Vouch software are the trust anchors of the entire architecture, their integrity is governed as a continuity control. DIRK and Vouch are developed under a secure development lifecycle (A.8.25, A.8.28): peer code review, dependency and supply-chain management, and testing with promotion gated through UAT. Build images are produced by a controlled, reproducible pipeline and are signed; only signed, provenance-verified images may be deployed, and provenance is verified before any server joins a pod (A.8.9, A.8.19). Changes to the build follow the ISMS change-management process. This prevents a defective or tampered build becoming a single point of correlated failure across pods. Third-party client binaries (execution and consensus clients) are obtained only from official sources, pinned to a specific version and SHA-256 checksum in the change-controlled deployment configuration, and verified against that checksum on download; a mismatch aborts the deployment.

7.8 Planned Maintenance and Rolling Upgrades

The 3-of-5 threshold architecture also lets Attestant maintain and upgrade its infrastructure without downtime or slashing risk. DIRK signers are patched and upgraded one at a time: a signer is stopped, upgraded and restarted while the remaining signers continue to meet the quorum, and the restarted signer is observed for two epochs (~13 minutes) — long enough to confirm its keys are signing correctly — before the next signer is taken out. Beacon nodes are upgraded the same way: because Vouch draws on multiple beacon nodes, any one can be taken offline and upgraded while Vouch continues uninterrupted on the others. Routine maintenance and, importantly, the prompt application of security patches (A.8.8) are therefore carried out as planned changes, with no interruption to signing and no exposure to slashing.

8. Recovery Objectives

Notes on recovery objectives:

• Not all rebuilds are equal, and only the rarest needs the full team. Losing one or two signers does not stop signing — the 3-of-5 quorum continues — and the affected signer is rebuilt by its stripe key-holder without time pressure. A Vouch rebuild involves no key material: failing over to a pre-authorised standby Vouch is an operations task, while standing up a new Vouch identity needs a key-holder-supervised change to the signers’ allow-list. Only a full-pod rebuild — all signers lost, signing already ceased — requires several stripe key-holders to be physically assembled with their offline shards and hardware keys; it is rare and paced by that assembly, not by a technical target. On the build times recently observed, a Vouch server takes on the order of 12 hours — most of it the execution clients re-synchronising to the chain — and a DIRK signer about 6 hours, including the lock-down sequence even with the stripe key-holder already online. A full-pod rebuild is paced by the slowest element (a Vouch server) and by assembling the stripe holders, so it is on the order of 12 hours or more.

• Crucially, these rebuild times sit on the critical path only in an extreme, correlated loss. A Vouch server can be lost with no interruption to signing: the pod’s standby Vouch — and, if needed, the dedicated out-of-pod BCP Vouch — carries signing while the failed server is rebuilt in the background, and the Vouch rebuilds performed to date have been completed with no impact to validator operations. For the 12-hour Vouch build to delay recovery at all, a pod would have to lose its primary, its in-pod standby and its out-of-pod BCP Vouch at the same time — a correlated, cross-location failure the redundancy exists to prevent (and, for a full-pod outage, the 3-of-5 DIRK quorum on top of that). In normal operation a Vouch or single-signer rebuild therefore causes no downtime; the measured build times bear on recovery only in a near-total simultaneous loss.

• The near-zero RPO in steady state is a structural property of the DIRK threshold architecture: the slashing-protection state is held on durable storage across the quorum, so no single-node loss costs state. In a total-pod loss the authoritative recovery point is the chain itself — the rebuilt signer reconciles against it before signing — rather than an off-box backup of the signing store, which Attestant deliberately does not keep.

• The 30-minute RTO is contingent on there being no ambiguity about signing state. Where ambiguity exists, the wait period (minimum 2 epochs, ~13 minutes) must be observed before restoration is permitted.

• Maximum Tolerable Downtime for validator operations is 24 hours. This reflects the point at which foregone client rewards, and contractual and reputational impact, become material — it is not driven by the protocol inactivity leak, which applies only during network-wide non-finality and is outside Attestant’s control. It is set with margin over the measured worst case: a full-pod rebuild is paced by the Vouch build (on the order of 12 hours) and by assembling the stripe holders, and so sits comfortably within this window. That window is only ever reached in an extremely rare event — a pod losing both of its Vouch servers and the dedicated off-site BCP Vouch at the same time (and, for a full-pod outage, the 3-of-5 DIRK quorum as well). Resilience is a first-class design goal alongside security: two Vouch servers per pod plus an off-site BCP instance exist precisely to keep effective operational downtime far below this boundary. Where a client agreement cites a downtime figure, it is understood as expressing tolerance for effective operational downtime — an inability to validate — rather than the time to rebuild any single component, which the redundancy renders an extremely improbable cause of actual downtime. The basis for this figure is maintained with the Business Impact Analysis (Section 10).

• Quorum restoration provisions new bare-metal instances from hardened, provenance-verified builds, following the internal DIRK re-initialisation protocol; no key material is exposed during this process and the 3-of-5 senior-manager shards are required.

9. BCP Trigger Criteria

The following conditions are formal triggers for BCP invocation. Detection of any trigger must be reported to the CRO or COO immediately, regardless of time of day; the CRO or COO declares a BCP event and initiates the appropriate response.

10. Business Impact Analysis

Impact severities below are derived from financial exposure (loss of client principal for slashing; foregone rewards for downtime), client contractual commitments and reputational impact; quantified figures are maintained alongside this analysis in the ISMS risk register and inform the recovery objectives in Section 8.

10.1 Slashing

Critical severity. Slashing causes direct, irreversible financial loss to clients (reduction of staked ETH principal), forced validator exit and significant reputational damage. The asymmetry — a brief operational error can cause a loss that dwarfs extended downtime penalties — is the primary driver of the Safety-First philosophy.

10.2 Inactivity / Downtime

High severity, but recoverable. While a validator is offline it incurs ordinary missed-attestation penalties that are broadly equal to the rewards foregone and are recovered over an equivalent period of uptime; downtime does not cause forced exit. This is distinct from the protocol inactivity leak, which applies only during network-wide non-finality. Because downtime is recoverable, it never justifies actions that introduce slashing risk.

10.3 Monitoring Degradation

Medium severity. Loss of monitoring does not directly cause financial loss but materially impairs Attestant’s ability to detect and respond to other failures. Monitoring is treated as essential support infrastructure and restored with high priority.

10.4 Corporate System Outage

Low severity from a staking-continuity perspective (4-hour RTO acceptable). Email, communications and documentation outages do not impair validator operations. Extended unavailability could affect incident coordination and client communication, but these have an out-of-band fallback — the incident contact register (Section 13.1) — so a corporate-systems outage does not block escalation or client notification. The incident contact register, this policy and the core recovery runbooks are additionally held out-of-band on Attestant’s WireGuard-protected internal documents server — bare-metal infrastructure independent of Google Workspace and reached without Google sign-in — so the documents needed to run an incident remain available even if Workspace is unavailable; the wider corporate document set resides in Workspace and is recoverable from the Afi backup. The 4-hour figure reflects the Google Workspace dependency, not Attestant’s only means of communicating.

11. Infrastructure Resilience

11.1 Multi-Vendor, Multi-Jurisdiction Model

Infrastructure is deployed across multiple independent hosting providers in multiple jurisdictions so that no single provider failure, regional outage or localised disaster can impair the signing quorum. No single provider hosts more than 40% of the validator fleet — a consequence of the per-pod rule (below) that no provider holds more than two of a pod's five signers. Provider selection and concentration are reviewed on an ongoing basis and at the annual BCM review (see Section 12).

Per-pod placement (signers and validators). Each pod’s five DIRK signers are placed so that no single hosting provider holds more than two of them and no single jurisdiction holds three or more, giving the 3-of-5 quorum tolerance to the loss of any single provider or jurisdiction. The same diversity principle applies to the rest of the pod: a pod’s Vouch validator servers (primary and standby) are placed on different hosting providers, in different data centres, and in different geographical regions — in Europe a different country/jurisdiction, and in the USA a different state — so that no single provider, facility or regional outage can disable both. Where a documented data-residency obligation requires a pod to remain within one jurisdiction, that pod is operated as a recorded exception: the limit of two signers per provider still applies and the five signers are distributed across several independent providers and physically separate facilities, so that no single provider, facility or localised outage can take the pod below quorum; the residual single-jurisdiction risk is assessed, accepted and recorded in the ISMS risk register, owned by the CRO. The per-pod distribution of all signing and validator servers across providers, locations and jurisdictions is maintained as evidence and reviewed at each BCM cycle.

11.2 Bare-Metal Control

All validator infrastructure runs on dedicated bare-metal servers using Attestant’s own hardened build. No third-party managed compute, containerised cloud services or shared infrastructure are used for any signing-related function, removing exposure to noisy-neighbour effects, hypervisor vulnerabilities and provider-side configuration changes affecting validator behaviour.

The only exception is DNS, for which Amazon Route 53 is used. Route 53 is isolated from the steady-state signing path; its unavailability does not impair ongoing DIRK threshold signing or Vouch attestation. DNS is, however, used during recovery to make replacement DIRK nodes visible to Vouch; this recovery-path dependency is mitigated by low record TTLs and a documented static-resolution fallback for Vouch-to-DIRK discovery, and the use of a single DNS provider is a recorded, risk-accepted item (see Section 11.6).

11.3 Access Control

Access to all servers requires multi-factor authentication including FIDO2 hardware security keys. No individual holds credentials to the entirety of the fleet; access is partitioned by function and reviewed quarterly. All access events are logged and monitored.

11.4 Backup and Durable State

Off-box backup supports recovery of operational and configuration state. The following are backed up to an independent, encrypted off-site store, with the last successful restore test recorded for audit. The validator signing / slashing-protection store is deliberately not among them — its resilience is structural (Sections 7.1, 7.6 and 8) and it requires no off-box backup:

• Operational database & mappings: the operations database, including the validator-key-id→customer-id mapping. The customer-id→customer-record mapping is held separately, so validator data and client identity are never co-located in one store.

• Configuration & images: DIRK and Vouch configuration, monitoring/alerting configuration, hardened build images, and the source repositories.

• Incident records: Incident logs (retained for a minimum of three years per Section 13.3).

The full validator key is never assembled on any machine — not when it is first generated (it is created distributively across the five signers, never built whole and divided) and not in any backup. It exists only as encrypted threshold shards (Section 7.6); individual shards are kept offline by their owners, but no single shard is the key and no backup ever brings the shards together, so no backup can become a single point of compromise. This control maps to A.8.13.

11.5 Beacon and Execution Nodes

Vouch depends on beacon and execution nodes for attestation duties. Attestant maintains redundant beacon and execution nodes across providers and regions, with diversity across execution-client implementations as well as consensus clients (Section 7.5), so that the failure or defect of any single node or client implementation does not halt attestation (A.8.14).

11.6 Cloud Services

Although validator signing uses no managed cloud services, Attestant relies on Amazon Route 53 (DNS) and Google Workspace (corporate). These are governed as cloud services under A.5.23: access to the Route 53 zone is restricted to senior managers and changes are logged; Google Workspace is governed by tenant security configuration, enforced MFA and the provider’s assurance reporting, and an independent third-party backup (Afi) of Workspace data to a separate store so that recovery does not rely on Google’s native retention alone. Afi is itself accessed through Google single sign-on (it holds no separate password of its own), so access to the Afi backup depends on Google identity being available; this dependency is recorded as a risk-accepted item in the ISMS risk register and, for the documents needed during an incident, is mitigated by the out-of-band copy described in Section 10.4.

12. Third-Party Dependencies and Supplier Management

Attestant’s operations involve a deliberately limited set of third-party dependencies. The table identifies critical dependencies and their continuity controls, supporting compliance with A.5.19–A.5.22.

All hosting-provider agreements are subject to annual review and must contain Attestant’s required security terms (A.5.20). Attestant permits no single provider to hold a controlling share of validator nodes. Provider performance, incident history and any changes to their services are reviewed as part of the annual BCM cycle (A.5.22).

13. Communication and Escalation

13.1 Internal Escalation

Any staff member who identifies or suspects a trigger condition must notify the CRO/COO and Lead Engineer immediately via the primary communication channel. If that channel is unavailable, the designated out-of-band method in the Attestant incident contact register must be used. The CRO or COO declares a formal BCP event.

13.2 Client Notification

For a confirmed slashing event or any incident causing material validator downtime, the CRO (or COO) notifies affected clients, in line with contractual commitments (Section 2):

• Confirmed slashing event: notification within 4 hours of confirmation.

• Validator downtime exceeding RTO: notification within 24 hours of the RTO breach.

• Extended outage or major incident: interim updates as appropriate until resolution.

Client notifications are recorded in the incident log alongside all technical actions; notification content is reviewed by the CRO before transmission.

13.3 Incident Logging and Evidence

All BCP events are logged in Attestant’s incident-management system from detection through closure, capturing: time of detection; trigger condition; actions taken; personnel involved; CRO/COO decisions and authorisations; client notifications; and post-incident findings. This procedure operates under the ISMS incident-management controls (A.5.24–A.5.27). For security incidents, evidence is preserved with appropriate chain-of-custody (A.5.28). Incident logs are retained for a minimum of three years and form the primary evidence base for BCM testing reviews and external audits.

14. Emergency Action Process

The CRO or COO, with senior management, manages responses to all critical incidents. The following applies to every BCP activation:

1. Detection: evaluate validator state, signing activity, quorum integrity and monitoring outputs to confirm the trigger and assess severity.

1. Isolation: if double-signing risk exists or cannot be excluded, immediately isolate affected infrastructure from the signing path. Vouch shutdown may be automatic or manual.

2. Client mitigation: if the trigger is client-specific, initiate emergency migration to a diverse implementation per Section 7.5.

3. Wait period: if signing state is ambiguous, enforce a minimum wait of 2 epochs (~13 minutes) before any restoration; may be extended at CRO/COO discretion.

4. Restoration: resume signing only after (a) original-instance termination is confirmed; (b) EIP-3076 slashing-protection data has been imported and verified; (c) quorum integrity is confirmed; and (d) the CRO or COO (or the Section 5 deputy authorisers, if both are unavailable) has given written authorisation.

5. Post-incident review: within 5 business days of closure, document root cause, response effectiveness and recommended changes, and raise any corrective actions in the ISMS register (Section 15.4).

15. Testing and Review

15.1 Annual Testing

Attestant conducts annual BCM drills covering at least the following scenarios:

• DIRK safe cessation: simulate loss of 3 of 5 signing nodes and verify auto-shutdown and recovery.

• DIRK resilience: simulate loss of 2 of 5 signing nodes and verify signing continues uninterrupted.

• Validator-client migration: execute an emergency migration from one consensus or execution client to another.

• Client-vulnerability response: tabletop exercise simulating discovery of a critical client bug and execution of the diversity trigger.

• Hosting-provider outage: simulate loss of all nodes at one provider and verify quorum is maintained.

• ESD path: trigger the ESD daemon and verify the primary, standby and BCP Vouch instances are inhibited and that controlled restoration requires CRO/COO authorisation.

• Signer rebuild: rebuild a signer and verify its slashing-protection state is re-established (imported from the surviving pod and reconciled against the chain) before signing.

• Key-personnel unavailability: verify recovery with alternative authorised engineers, and verify the Section 5 deputy authorisation path when both CRO and COO are unavailable.

• Key-shard availability: rebuild a pod with one shard-holder unavailable, confirming the 3-of-5 threshold still permits recovery.

• Network partition (Trigger 8): simulate regional isolation that creates ambiguous signing state; verify controlled downtime, enforcement of the wait period, and no double-sign when the partition heals.

• Intrusion response (Trigger 6): tabletop a suspected or confirmed unauthorised access to signing infrastructure, covering isolation, evidence preservation and escalation.

• Trust-anchor compromise (Trigger 9): tabletop the loss of a senior-manager key shard (re-share / DKG) and a compromised build pipeline (signed-image re-issue and blocking unverified builds from joining a pod).

• DNS fallback: rebuild a signer with Route 53 unavailable, exercising the static Vouch-to-DIRK resolution fallback.

• Monitoring blindness (Trigger 7): drop monitoring and telemetry visibility across a pod (technical simulation) and verify that signing state can still be confirmed via the beacon API and on-box checks, that the team falls back to manual verification safely, and that monitoring is restored within target.

A trigger-to-test matrix is maintained that maps every trigger in Section 9 to its exercise type — live drill, technical simulation or tabletop — and the date last performed; not every trigger is exercised live each year.

15.2 Test Documentation

All tests are documented with: date; scenario; participants; observed response timelines; comparison against RTO/RPO targets; and identified gaps or improvements. Test reports are retained as part of the ISMS evidence record.

15.3 Policy Review

This policy is reviewed annually and following any of: a live BCP activation; a material change to the Ethereum consensus protocol or client landscape; a change in hosting-provider arrangements; a significant security incident; or any regulatory or contractual change affecting continuity obligations. The CRO initiates and completes each review cycle.

15.4 Continuity Objectives and Metrics

Attestant maintains measurable continuity objectives, reviewed at the BCM cycle (ISO 27001 clauses 6.2 and 9.1): mean time to detect a trigger condition; drill RTO/RPO pass rate against the Section 8 targets; number of double-sign attempts prevented by automated controls; and percentage of planned drills completed. Post-incident and drill findings are raised in the ISMS corrective-action register and tracked to closure under clause 10.2 (nonconformity and corrective action), feeding the continual-improvement loop (clause 10.1).

Appendix A. Anti-Slashing Failover Checklist

This checklist must be completed and signed off whenever validator instances are migrated, standby servers are promoted, or any change is made to active signing infrastructure. No step may be skipped without CRO written authorisation. The completed checklist must be attached to the relevant incident or change record. Where this checklist calls for CRO or CRO/COO authorisation or verification, the Section 5 deputy authorisers (the Lead Engineer together with a senior key-shard holder) may act in their place when both the CRO and COO are unavailable — applying the same Safety-First decision test, with the decision and rationale logged for CRO review.

ESD pre-condition (mandatory before any step below): if the restoration follows an Emergency Shut-Down (ESD) event, the completed root-cause analysis and explicit CRO/COO ESD-clearance must be attached, and the primary, standby and dedicated BCP Vouch instances confirmed inhibited and unable to auto-restart, before Step 1 begins. The anti-slashing gates in this checklist — isolation/termination (Step 1), the ambiguous-state wait (Step 3), the EIP-3076 import and integrity verification (Step 5) and the quorum check (Step 6) — are not waivable for uptime pressure.

Incident / Change Reference: ______________________

Date: ______________________ Lead Engineer: ______________________

CRO/COO Signature: ______________________ Date & Time of Authorisation: ______________________

Appendix B. ISO/IEC 27001:2022 Control Mapping

This document contributes to compliance with the following Annex A controls:

END OF DOCUMENT — BC.PR.01 Rev 7 (Working Baseline) · Attestant Ltd · 29 June 2026