DORA Compliance-Officer End-to-End Scenarios

Pack: DORA Operational Resilience Pack — claim boundary operator-support

Audience: QA / Test Automation agents executing live-stack verification of the DORA Operational Resilience Pack, written from the perspective of a financial-entity operator’s compliance officer.

Claim boundary — read first. Stella’s DORA pack is operator-support. Stella helps the operator collect evidence, prepare signed handoff artifacts, track deadlines, retain artifacts, and run offline verification. It does not make the operator “DORA compliant”, does not submit anything to a competent authority, and is not legal advice. The operator remains the regulated/reporting party. Never write or assert copy of the form “Stella is DORA compliant” or “turn on DORA-compliant mode” (see docs/compliance/README.md → Forbidden product copy). Every scenario below ends with an explicit claim-boundary note describing what stays operator-supplied.

These scenarios are deliberately split by runtime surface:

The single most important live forcing function for DORA is the advanced-assurance-golden QA fixture import (POST /api/v1/qa/fixtures/advanced-assurance-golden/notify-import, scope notify.operator). It builds and persists a real DORA Article 19 incident timeline (open → classify → initial_report → intermediate_report) that is then queryable through the read-only regulatory timeline API. This is the same path the compliance golden-path script (devops/compose/scripts/compliance-golden-path.sh) uses for NIS2.

Live-stack facts (verified against src/)

• Base URL: https://stella-ops.local (self-signed → ignoreHTTPSErrors), resolve to 127.1.0.1 if hosts mapping is absent.
• Admin: admin / <the password your installer printed>, home tenant default. The OIDC login form pre-fills a stale password that must be cleared/overridden.
• Token (API path): POST {BASE}/connect/token at gateway root, grant_type=password, client_id=stellaops-cli, tenant=default. The stellaops-cli client successfully mints notify.viewer notify.operator scopes at runtime (proven live by compliance-golden-path.sh step 0/9). The Notify regulatory + assurance endpoints require the notify.viewer policy; the QA fixture import requires notify.operator.
• Tenant header: Notify reads the tenant from the JWT stellaops:tenant claim for the regulatory/assurance routes; the QA fixture import additionally requires the X-StellaOps-TenantId header.
• Concurrent-QA lock: if token mint fails, the admin user may be locked by a parallel agent — unlock with UPDATE authority.users SET failed_login_attempts=0, locked_until=NULL WHERE username='admin'.
• Reporting-timeline response (eu-reporting-timeline.v1): { schemaVersion, items[], cursor, sourceOfTruth:"Notify" }. Each item: regime, incidentId, state (uppercased), openedAt, milestone, deadline, deadlineStatus, replayHash (sha256:…), evidenceRefs[], milestones[] (each name, transmissionKind, deadline, deadlineStatus, requiredEvidence[]), transmissions[].
• DORA profile (dora.article19.incident): milestones initial-report (PT4H), intermediate-report (PT72H), final-report (P1M); claimBoundary: operator-support; runtimeRegimeId: dora.
• EBA RoI taxonomy pin (the freshly-landed validation): eba-reporting-framework-4.0-taxo-package-4.0-errata5, vendored at docs/contracts/schemas/eu/dora/roi/eba-reporting-framework-4.0/taxo_package_4.0_errata5/taxo_package_4.0_errata5.zip (outer SHA-256 sha256:2cf8a0fe6aadee36a5bf07403d7bd63a43cab96f98fad8251c31938e8242e2fb). Conformance label flips from not-claimed (EBA taxonomy not loaded) → claimed-against:eba-reporting-framework-4.0-taxo-package-4.0-errata5. Fail closed (DoraRoiTaxonomyLoadException) on SHA mismatch / missing package.

Scenario DORA-S1 — Major ICT incident: classify, report milestones, signed handoff

Compliance-officer narrative. A core payment-authorisation outage is opened. As compliance officer I must (a) classify it against the seven DORA criteria (EU 2024/1772), (b) hit the Article 19 reporting milestones — initial report within 4h, intermediate within 72h, final within 1 month — and © produce a signed, replayable handoff artifact for each variant that I can verify offline before my legal team files it with the competent authority.

Live surface (Notify timeline).

1. Drive a DORA timeline into the stack via the golden fixture: POST /api/v1/qa/fixtures/advanced-assurance-golden/notify-import (header X-StellaOps-TenantId: default, body seedManifest with fixtureId: advanced-assurance-golden and stableIds.doraIncidentId).
2. Query the persisted DORA timeline: GET /api/v1/regulatory/reporting-timelines?regime=dora&incidentId=<doraIncidentId>.
3. Read the profile + deadline policy: GET /api/v1/assurance/reporting-timeline-profiles/dora.article19.incident.

Expected assertions.

• Fixture import returns a timelines[] entry with regime: "dora" and a replayHash of shape sha256:<64 hex>.
• Timeline query returns sourceOfTruth: "Notify" and items.length >= 1.
• The DORA item’s milestones[].name set contains initial_report and intermediate_report (the fixture advances these two; final_report remains pending — that is correct, the final report is P1M out).
• The item regime is dora, replayHash is sha256:…, and at least one transmissions[] row carries dora_major_incident_classification_ref in its evidenceRefs.
• Profile dora.article19.incident returns claimBoundary: "operator-support", frameworkId: "dora", and a milestone with dueWithin: "PT4H" (milestoneId: "initial-report").
• Determinism: re-querying the timeline returns the identical replayHash.

CLI/offline leg (signed handoff — execute only when the stella CLI is built and a DORA report fixture input is available; otherwise record as a documented gap, do not fake). stella export dora-incident-report <id> --variant initial → XBRL + inline-XBRL + envelope + DSSE + handoff-manifest; then stella verify dora-incident-report <dir> asserts isValid: true, artifact-hash match, DSSE payload binding, and reproducible local HMAC. The seven-criteria classifier (stella incident classify) emits a stable classification hash across two clean runs.

Claim-boundary note. Stella classifies frozen facts and produces a local-contract handoff (local HMAC tamper check, not CAdES/KMS signing and not a regulator receipt). Official EBA incident XBRL validation is still blocked pending the eba-dora-incident-reporting-framework-4.3 pin. LEI, jurisdiction, financial-entity status, operator approvals, and the act of filing remain operator-supplied.

Scenario DORA-S2 — Register of Information: annual B.01–B.14 bundle + official EBA validation

Compliance-officer narrative. Once a year I must submit the Register of Information describing every ICT third-party arrangement supporting a critical or important function. I produce the B.01–B.14 bundle, validate the EBA-canonical templates (B.01–B.07) against the official EBA RoI 4.0 errata5 taxonomy, bind it to last year’s bundle hash, set retention, sign it, and verify the whole thing offline. If the EBA package is missing or tampered, the bundle must fail closed to a local-contract posture rather than over-claim.

Live surface (ExportCenter discovery — GET-only).

• GET /v1/exports/assurance/profiles?frameworkId=dora lists the DORA export profiles, including dora.roi.
• GET /v1/exports/assurance/profiles/dora.roi returns the profile metadata (SigningRequired, SupportsOfflineVerification).
• GET /v1/exports/assurance/profiles/dora.roi/readiness returns fail-closed readiness. Both routes require the export.viewer policy.

Expected assertions (live).

• The profile list contains a profile whose id is dora.roi and whose frameworkId resolves to dora.
• dora.roi readiness fails closed with a state/status that is not configured/ready and surfaces an operator-controlled reason (dora-roi-register-source-missing / dora-roi-owner-approval-missing per the contract; assert the readiness object is present and non-ready rather than pinning an exact reason string, since reason wiring is service-owned).
• There is no live POST export-trigger for dora.roi on the stack today (see Gaps). The spec asserts the GET surfaces and records the missing POST as a documented gap — it does not fabricate a trigger.

CLI/offline leg (RoI bundle production + EBA flip — the load-bearing behavioural proof). stella export dora-roi --year … --tenant … --input <register.json> --signing-key-file <hmac> --offline produces a deterministic ZIP (index.json, manifest.json, signature.json, templates/*.xml). When the vendored EBA package resolves and B.01–B.07 each map to a canonical b_NN.NN.xsd, the manifest.json regulatoryConformance flips to claimed-against:eba-reporting-framework-4.0-taxo-package-4.0-errata5; with the package absent / SHA-mismatched the export fails closed (DoraRoiTaxonomyLoadException) and the bundle stays on its-eu-2024-2956-local-contract-v1. stella verify dora-roi <zip> re-derives template + bundle hashes, the canonical-index DSSE binding, prior-year hash, and local HMAC, returning isValid: true.

Expected offline assertions. bundle/template hashes are byte-stable across two clean runs; manifest.json.ebaTaxonomyPin == eba-reporting-framework-4.0-taxo-package-4.0-errata5; ebaTaxonomyOuterSha256 == sha256:2cf8a0fe…e2e2fb; conformance label flips on present-pin and stays not-claimed on absent/mismatched pin; verify reports isValid: true.

Claim-boundary note. Validation is XSD-structural (template→XSD mapping + XML well-formedness against the SHA-pinned package) — not full XBRL DPM/dimensional/formula conformance, which stays a residual follow-up. Stella does not alter the EBA package and does not represent that EBA has certified or endorsed Stella. Financial-entity identity, contract terms, deeper subcontracting-chain ranks (operator-filled, must carry provenance), and the filing decision remain operator-supplied.

Scenario DORA-S3 — TLPT evidence: scope → baseline → signed EvidenceLocker capsule handoff

Compliance-officer narrative. For Threat-Led Penetration Testing I (white team) must hand the TLPT testers a frozen, approved scope and a replay baseline, then seal a signed EvidenceLocker capsule of the test evidence that an auditor can verify offline — without Stella ever running offensive tooling or choosing targets for me.

Live surface. None today for TLPT scope/baseline/pack production: the TLPT flow is CLI/offline-only (stella tlpt scope|baseline|pack, stella replay, stella verify tlpt-pack). The Assurance export profile dora.tlpt-evidence-pack is discoverable via GET /v1/exports/assurance/profiles?frameworkId=dora (metadata only). Live Graph asset-registry query mode and EvidenceLocker TLPT audit-action emission are service-owned follow-ups (not yet wired).

CLI/offline leg. stella tlpt scope (asset-registry + reachability subgraph → tlpt-scope.v1) → stella tlpt baseline (binds scope, writes tlpt-baseline.v1, self-verifies hash) → stella replay <baseline> (offline hash verify; tampered baseline fails closed baseline-hash-mismatch) → stella tlpt pack (Ed25519-signed tlpt-pack-cli-bundle.v1) → stella verify tlpt-pack (schema + canonical content hash + TLPT DSSE payload type + Ed25519 signature).

Expected assertions. scope hash + baseline hash are stable; tampered baseline yields VerificationFailed / baseline-hash-mismatch; pack verify reports valid for a clean pack and VerificationFailed for a mutated manifest or wrong key.

Live assertion for the spec. Assert that dora.tlpt-evidence-pack is present in the live Assurance export profile list (proves the pack surface is discoverable) and record the scope/baseline/pack production as CLI-only.

Claim-boundary note. Stella never launches offensive tooling, never infers the legally-required TLPT scope without operator approval, and never presents CLI output as a regulator receipt. Scope approval, execution, findings treatment, and reporting are operator-supplied.

Scenario DORA-S4 — Article 45 information sharing: STIX/TAXII batch via the dora-info-sharing channel

Compliance-officer narrative. Under our sharing arrangement I send a minimised, signed cyber-threat batch to a peer bank. It must go through a dedicated dora-info-sharing purpose channel (never an ordinary notification channel), be STIX 2.1 / TAXII 2.1-aligned, be PII-minimised by default, be DSSE-signed, and only deliver after subscriber approval and trust material are in place.

Live surface (Notify channels).

• GET /api/v2/notify/channels (scope notify.viewer) lists channels; a DORA sharing channel carries config purpose: dora-info-sharing and enabled.
• PUT /api/v2/notify/channels/{id} (scope notify.operator) upserts a channel.
• The Assurance export profile dora.info-sharing is discoverable via GET /v1/exports/assurance/profiles?frameworkId=dora.

Expected assertions (live).

• dora.info-sharing appears in the live DORA Assurance export profile list.
• A dora-info-sharing-purpose channel, when present/created, reports purpose: "dora-info-sharing" and starts disabled (enabled: false) until operator setup completes — the fail-closed default. (If channel create/list is not exercised on the shared lab tenant to avoid cross-agent state churn, assert the profile discovery and record channel setup as operator-controlled.)

CLI/offline leg. stella export dora-info-sharing --input <batch.json> --signing-key-file <hmac> builds the STIX bundle + TAXII manifest + DSSE envelope + receipt, with strict minimisation dora-info-sharing-strict-v1; stella verify dora-info-sharing verifies the DSSE envelope offline.

Claim-boundary note. Notify stores only references/public metadata — never raw credentials, private keys, or broad PII allowlists. Delivery fails closed if the channel purpose is wrong, the channel is disabled/endpoint-less, subscriber approval is missing/expired, the DSSE envelope does not verify, egress is not allowlisted, or redaction would include non-allowlisted PII. The sharing arrangement, subscriber authorisation, transfer basis, and the decision to deliver each batch are operator-supplied.

Scenario DORA-S5 (Console UI) — Compliance officer reviews DORA readiness in /assurance

Compliance-officer narrative. Before any export I open the Console Assurance shell to confirm the DORA pack is enabled as operator-support, see its readiness (e.g. retention-policy review required), and drill into the dedicated DORA review workspace.

Live surface (UI). /assurance shell (route guarded by requireComplianceGuard) and /assurance/dora/review. This requires the UI-session token (real OIDC login as admin), which carries the notify.viewer / export.viewer scopes + correct audiences (the stella-ops-ui client). The spec performs a real OIDC login (clearing the stale pre-filled password) and asserts the rendered DORA card + claim boundary.

Expected assertions. the DORA pack card renders “DORA Operational Resilience Pack” with claim-boundary operator-support; a “Review workspace” link points to /assurance/dora/review; the review workspace renders the DORA review heading. No forbidden “DORA compliant” copy appears.

Claim-boundary note. The shell is a discovery/readiness surface only; enabling the pack does not file anything and does not assert compliance.

Execution order recommendation

1. DORA-S1 (timeline) and DORA-S2 live discovery and DORA-S4/S3 profile discovery are pure API and the fastest, most reliable live proofs — run first. They share one notify.viewer/export.viewer token.
2. DORA-S5 (UI) needs a browser OIDC login — run after the API legs.
3. The CLI/offline legs (S2 RoI EBA flip, S1 signed handoff, S3 TLPT, S4 info-sharing batch) are the deepest behavioural proofs but require the stella CLI to be built and fixture inputs; a later wave should execute them against the .csproj test suites (StellaOps.Findings.DoraRoi.Tests, StellaOps.Cli.Tests, StellaOps.Notify.Connectors.Dora(.InfoSharing).Tests) per QA Tier 2d, or via the built CLI .exe. They are documented here for completeness and are not driven by the Playwright specs (Playwright cannot meaningfully drive the offline CLI signing flow).

Gaps surfaced (do NOT fix — report only)

• No live POST RoI/incident/info-sharing/TLPT export trigger. ExportCenter GET /v1/exports/assurance/profiles[...] is metadata + readiness only; actual DORA bundle production is CLI-only. The task brief’s “POST /v1/exports/...” does not exist for DORA today.
• EBA RoI validation is CLI/library-only. The conformance flip lives in StellaOps.Findings.DoraRoi + the CLI; it has no HTTP surface, so the live Playwright spec can only assert the dora.roi profile + fail-closed readiness. The flip itself is verified by Tier-2d tests / built CLI.
• EBA incident XBRL validation still blocked pending the eba-dora-incident-reporting-framework-4.3 pin (RoI is the only regime with the official taxonomy vendored).
• DORA timeline rows are seeded via a QA fixture import, not a production incident-ingest path; the read API is read-only. The “real” DORA incident producer is the Telemetry classifier + CLI, not a live POST.
• stellaops-cli seed scopes vs. runtime. The S001 seed lists the CLI client with authorization_code,device_code grants and without notify scopes, yet the golden-path script mints notify.viewer notify.operator via password grant successfully — confirm the runtime grant/scope allowlist (later migration or Authority config) before relying on it; specs fall back to the UI-session token if the password grant is rejected.