DORA Article 45 Information-Sharing Runbook

Owner: Notify platform Audience: Financial-entity operators, SOC leads, compliance officers Contract: DORA Info Sharing Event Contract v1 Decisions: DORA-Q1 and DORA-Q5 Related Notify channel model: Notification Channels

Scope

The DORA information-sharing channel is an operator-controlled outbound feed for DORA Article 45 cyber-threat and incident information sharing. The v1 canonical format is a STIX 2.1-aligned JSON bundle, a TAXII 2.1 collection manifest, and a DSSE envelope around each exported batch.

This runbook is for operating the channel. It does not make Stella the regulated financial entity or the legal owner of a sharing arrangement. The tenant operator owns the subscriber list, authorisations, transfer basis, retention, and decision to deliver a batch.

General Notify channels must not be reused for DORA peer sharing. Use a Notify channel whose purpose is dora-info-sharing so minimisation, signing, and audit evidence stay separated from ordinary notifications.

Runtime Boundary

Sprint 141 delivered the connector-local primitives, Sprint 208 wired the smallest live Notifier runtime path, and Sprint 20260605.005 split the Worker compile boundary so executable connector code is mounted instead of compiled into the Worker image:

• STIX 2.1-aligned event batch export for incident, indicator, and threat-actor objects.
• TAXII 2.1 collection manifest generation.
• DSSE signing and offline verification helpers.
• Schema-level strict and explicit-authorisation redaction profiles.
• Worker dispatch for an already persisted and operator-enabled NotifyChannelPurpose.DoraInfoSharing channel.
• A host-owned StellaOps.Notify.Connectors.DoraInfoSharing.Contracts package for request/result/signer/verifier contracts.
• A Notifier Worker mounted-runtime adapter that loads the executable StellaOps.Notify.Connectors.DoraInfoSharing assembly from the configured Notify plugin directory.
• Signed mounted-bundle admission for the regulatory profile when notifier:dora:infoSharing:connector:EnforceSignatureVerification=true.

The CLI can generate a disabled feed setup document and can produce and verify an offline signed handoff.

The Notifier worker selects live DORA delivery by channel purpose, not by generic custom or webhook type. A DORA machine payload queued against a non-DORA-purpose channel fails closed before any subscriber POST, so ordinary custom webhooks cannot accidentally receive STIX/TAXII batches.

Live runtime delivery starts from an already persisted, enabled channel. The stella notify setup-dora-feed --url <ep> output remains disabled by default for operator review; an approved operator or API flow must persist and enable the channel before queued source events can be dispatched. Supported operating modes are:

• produce-and-sign filesystem handoff: export the signed bundle, manifest, and receipt file to an operator-controlled filesystem or Evidence Locker location, then hand off or upload under the tenant’s own approved procedure; or
• connector-local delivery in controlled tests or a Notify worker integration that persists the returned NotifyDelivery and receipt through the existing delivery-ledger repository.
• Notifier worker live delivery: load the enabled dora-info-sharing channel, build DoraInfoSharingExportRequest from the channel collection/subscriber settings and frozen source events on the pending delivery, load the mounted DORA info-sharing connector assembly, invoke its subscriber delivery service through the contracts-only surface, and persist the returned NotifyDelivery plus receipt metadata through the existing delivery-ledger repository. If the connector assembly is not mounted, the Worker fails closed before signing or subscriber transport with connector-bundle-not-mounted.

The signed regulatory profile uses these paths and manifest fields:

When signature verification is enforced, the Worker admits the bundle only after manifest.json binding, per-assembly sha256 verification, and detached <assembly>.sig verification against the configured trust root. A mounted unsigned bundle or a bundle signed by an untrusted key is rejected before the assembly is loaded; the worker probe row reports status=rejected with the signature reason. If the DORA profile is not enabled and optional plugins are not requested, a missing bundle is not emitted as a blocking row.

Prerequisites

Before enabling a feed, confirm:

• The tenant compliance profile identifies the financial entity and the sharing arrangement owner.
• A subscriber record exists with subscriber name, collection id, endpoint, jurisdiction/transfer notes, and subscriber id hash policy.
• The endpoint host is on the tenant outbound allowlist. Air-gapped kits block public internet egress by default.
• An Authority secretRef exists for TAXII credentials or peer upload credentials. Notify stores only the reference, never raw credentials.
• A signing key is available through the tenant-approved crypto provider.
• An operator approval record exists for the subscriber, redaction profile, key id, destination, and first export window.

Setup

1. Create a dedicated Notify channel.

   The channel must be disabled at creation time unless it is being restored from a previously approved manifest.

   CLI setup generates the disabled channel document without contacting a live TAXII endpoint:

   stella notify setup-dora-feed \
     --tenant tenant-bank-de \
     --url https://taxii.peer.example/api-root/collections/collection-tenant-a-dora \
     --collection-id collection-tenant-a-dora \
     --subscriber-id peer-bank-a \
     --secret-ref authority://secrets/notify/dora-taxii-peer-bank-a \
     --generated-at 2026-04-30T09:00:00Z \
     --output ./out/dora-info-sharing-feed.json
   

   The generated document uses schema dora-info-sharing-feed-setup-v1, sets purpose to dora-info-sharing, and sets enabled to false. It is a setup artifact for operator review. A Notify API/operator flow must persist the reviewed channel and enable it after approval; the Notifier worker consumes only the already persisted, enabled channel.

   {
     "name": "dora-info-sharing-peer-bank-a",
     "type": "custom",
     "purpose": "dora-info-sharing",
     "endpoint": "https://taxii.peer.example/api-root/collections/collection-tenant-a-dora",
     "secretRef": "authority://secrets/notify/dora-taxii-peer-bank-a",
     "enabled": false,
     "labels": {
       "regime": "dora",
       "article": "45",
       "subscriber": "peer-bank-a"
     }
   }
   

2. Bind the channel to one TAXII collection id.

   Use a stable collection id per subscriber and tenant. Do not multiplex unrelated subscribers through one collection because the audit evidence records collection_id and subscriber_id_hash per delivery.

3. Select the minimisation profile.

   Use dora-info-sharing-strict-v1 unless an explicit-authorisation approval names the subscriber, authorisation reference, and exact PII field allowlist.

4. Configure the signing key.

   Use a DORA information-sharing key or key alias separate from webhook, Notify ack-token, incident-reporting, and product-advisory keys. Publish the verification material to the subscriber through the approved trust channel.

5. Keep the channel disabled until approval.

   The connector live sender refuses disabled channels. Enable live delivery only after the tenant approval record exists. The Notifier runtime persists both the connector-returned NotifyDelivery row and the subscriber receipt metadata when it dispatches an approved channel.

Live Notifier Delivery

The live worker path is purpose-specific. It does not route through the generic WebhookChannelDispatcher, does not render human notification templates, does not fetch external schemas, and does not require a live OASIS service.

Delivery sequence:

1. Build the DoraInfoSharingExportRequest from the enabled dora-info-sharing channel, collection id, subscriber id, redaction profile, and frozen source events.
2. Sign the STIX batch through the configured batch signer.
3. Verify the generated DSSE envelope with the configured verifier before any HTTP request is sent.
4. POST a dora-info-sharing-taxii-delivery-v1 JSON body to channel.config.endpoint.
5. Persist the returned NotifyDelivery ledger entry and dora-info-sharing-subscriber-receipt-v1 receipt through the Notify delivery-ledger repository.
6. Mark the original queued source delivery as completed or failed with a pointer to the connector ledger delivery id and receipt metadata; remove the frozen source-event JSON from the completed queue record so source payloads are not retained there after dispatch.

The POST body contains the TAXII manifest, STIX batch, DSSE envelope, payload hashes, collection id, channel id, and subscriber id hash. Subscriber responses with a 2xx status are recorded as accepted; non-2xx responses are recorded as rejected; signature, disabled-channel, missing-endpoint, timeout, and transport errors are recorded as failed.

Redaction And Minimisation

Strict profile behavior:

• Removes every source-event pii field.
• Removes free-text descriptions before canonicalization.
• Emits x_stella_minimisation on every STIX object with profile id, mode, and redacted field names.
• Hashes tenant, source event, and subscriber identifiers where the contract requires hashes.

Explicit-authorisation profile behavior:

• Requires an operator approval reference.
• Requires a field allowlist such as contact_email.
• Emits only allowlisted values under x_stella_authorised_pii.
• Emits only authorisation_ref_hash, not the full authorisation reference.
• Scrubs non-allowlisted PII from any authorised free-text description before signing.

Operators should treat explicit-authorisation mode as exceptional. Before using it, record why strict mode is insufficient, who approved the exception, when it expires, and which subscriber can receive the fields. Do not add broad fields such as “all customer identifiers” or “all analyst notes”; translate the need into concrete field names.

Key Management

Use Authority or the tenant-approved KMS/HSM provider for signing and secrets:

• Store TAXII credentials as secretRef values. Never place tokens, passwords, private keys, or client certificates in Notify channel JSON, STIX bundles, or sprint/docs artifacts.
• Record signer key id, algorithm/profile, and rotation generation in the delivery evidence.
• Keep retired public keys available for verification until all retained DORA information-sharing evidence signed by those keys has expired.
• Rotate the signing key on the tenant’s crypto cadence and immediately after suspected compromise. Record old key id, new key id, approver, time, and affected channels.
• Re-run offline verification after rotation using an old signed batch and a new signed batch to confirm both active and verification-only keys work.

Regional crypto requirements, such as FIPS, eIDAS/QSealC, GOST, or SM profiles, are tenant policy inputs. The runbook requirement is that verification remains offline and tied to explicit key ids.

Export And Filesystem Handoff

Until live TAXII routing is wired, use this default handoff:

1. Generate the STIX batch from frozen source events and the approved redaction profile.
2. Generate the TAXII collection manifest for the subscriber collection.
3. Wrap the canonical STIX bytes in DSSE.
4. Write the following files to an operator-controlled directory or Evidence Locker capsule:
   • stix-batch.json
   • taxii-manifest.json
   • stix-batch.dsse.json
   • dora-info-sharing.receipt.json
5. Restrict the directory to the approving operator group and the transfer service account.
6. Verify the DSSE envelope offline before the file leaves the environment.

CLI export:

stella export dora-info-sharing \
  --input ./inputs/dora-info-sharing/batch.json \
  --output ./out/dora-info-sharing/peer-bank-a \
  --signing-key-file ./keys/dora-info-sharing.hmac \
  --signing-key-id eu-local-dora-info-sharing \
  --json

The input file uses schema dora-info-sharing-cli-input-v1 and contains the tenant id, collection id, generated timestamp, disabled channel metadata, redaction profile, and source events. The local HMAC key can also be provided through STELLAOPS_DORA_INFO_SHARING_HMAC_KEY. This local signature is an offline reproducibility and tamper check; it is not production CAdES/KMS signing or live TAXII submission.

CLI verification:

stella verify dora-info-sharing ./out/dora-info-sharing/peer-bank-a \
  --signing-key-file ./keys/dora-info-sharing.hmac \
  --signing-key-id eu-local-dora-info-sharing \
  --json

The receipt should contain:

{
  "schemaVersion": "dora-info-sharing-handoff-receipt-v1",
  "tenantId": "tenant-bank-de",
  "collectionId": "collection-tenant-a-dora",
  "generatedAt": "2026-04-30T09:00:00.000Z",
  "channelId": "chn-dora-info-sharing",
  "subscriberId": "peer-bank-a",
  "bundleId": "bundle--<deterministic-id>",
  "stixPayloadSha256": "sha256:<hex>",
  "signedEnvelopeSha256": "sha256:<hex>",
  "taxiiManifestSha256": "sha256:<hex>",
  "signingKeyId": "eu-local-dora-info-sharing",
  "artifacts": [
    {
      "fileName": "stix-batch.json",
      "mediaType": "application/vnd.stellaops.dora-info-sharing.stix-batch.v1+json",
      "sha256": "sha256:<hex>"
    }
  ]
}

Operator Approval

Approval is required before the first export to a subscriber, before enabling live delivery, and before any explicit-authorisation redaction profile is used.

The approval record must include:

• Tenant and channel id.
• Subscriber id or subscriber id hash.
• Endpoint and collection id.
• Redaction profile id and mode.
• PII allowlist and authorisation reference, if any.
• Signing key id and verification-material location.
• Export window or incident/intelligence scope.
• Approver identity, fresh-auth timestamp, reason, and expiry/review date.

Use separation of duties where the tenant requires it. A producer of the source event should not be the only approver for sharing the same event externally.

Audit Trail

For every attempted handoff or delivery, retain enough evidence to replay the decision offline:

• Source event refs and source event hashes.
• STIX payload hash.
• DSSE envelope hash.
• TAXII manifest hash.
• Signer key id and verification profile.
• Channel id, channel purpose, collection id, and subscriber id hash.
• Redaction profile id, mode, redacted field list, and authorisation ref hash when applicable.
• Operator approval ref.
• Delivery or handoff status, timestamp, actor/service account, and failure reason if the attempt did not complete.

Notifier live delivery persists these fields as delivery metadata on the connector-returned NotifyDelivery entry and mirrors receipt id/status/hash metadata onto the completed source delivery. For filesystem handoff, store the receipt beside the signed files and attach it to the operator approval or Evidence Locker capsule.

Verification

Before release from the tenant boundary:

1. Decode the DSSE payload.
2. Recompute the DSSE pre-authentication encoding for application/vnd.stellaops.dora-info-sharing.stix-batch.v1+json.
3. Verify at least one signature against local trust material.
4. Recompute the STIX payload hash and compare it with the receipt.
5. Recompute the DSSE envelope hash and compare it with the receipt.
6. Inspect x_stella_minimisation on a sample object from each object kind in the batch.
7. Confirm the channel purpose is dora-info-sharing.

Verification must not require a live TAXII endpoint or external schema fetch. The same frozen inputs, timestamp, redaction profile, and signer material must reproduce the same hashes.

Failure Handling

• Missing approval: do not export; record the blocked attempt and request approval.
• Endpoint not allowlisted: keep the channel disabled and update the tenant egress allowlist only through the normal change process.
• Missing secretRef: keep produce-and-sign available, but do not attempt live TAXII delivery.
• DSSE verification failure: quarantine the files, do not hand off, rotate or repair trust material as needed, and rerun the export from frozen inputs.
• Redaction violation: discard the batch, correct the profile or source-event classification, and regenerate. Do not patch signed payloads by hand.
• Subscriber rejects the batch: retain the rejection evidence with the receipt and delivery-ledger entry, then regenerate only after an operator-approved correction.

Offline And Air-Gap Expectations

The information-sharing connector must remain usable without internet access. Offline kits should carry local trust material, channel manifests with disabled placeholder endpoints, and deterministic fixtures. Operators replace endpoints and secretRef values during deployment validation.

No runtime path should fetch live OASIS, authority, peer, or SaaS schemas to validate v1. Schema or transport version changes require a new contract version and a new operator approval for affected subscribers.