DORA TLPT Operations Runbook

Version: 0.1.0 Sprint: 20260430_134 Last updated: 2026-04-30

Audience: White-team operators and Stella Ops platform operators at regulated (financial-entity) customers preparing for, handing off, and retaining evidence from a DORA threat-led penetration test.

This runbook describes how regulated customers use Stella Ops during DORA threat-led penetration testing (TLPT) preparation, handoff, and evidence retention.

Product boundary: Stella is white-team and evidence-side tooling only. It helps customer operators define scope, freeze replayable baseline evidence, assemble signed evidence packs, and retain verification artifacts. Stella is not red-team tooling and must not provide exploitation tooling, command-and-control tooling, phishing kits, credential attacks, payload generation, or red-team execution workflow.

1. Operating Model

DORA TLPT remains owned by the financial entity or other regulated customer. The customer appoints the white team, selects or contracts the red team, obtains required approvals, and controls competent-authority interactions. Stella only supports the evidence workflow around that governed exercise.

Party	Stella-facing responsibilities	Outside Stella
Customer/operator	Configure tenant compliance profile, approve retention settings, approve scope, approve baseline freeze, export and retain evidence.	Own DORA applicability, regulator liaison, legal authorization, red-team procurement, rules of engagement, and final submission.
White team	Use Stella to produce deterministic scope, bind a baseline hash, assemble signed packs, and record approvals.	Coordinate the TLPT exercise, decide what is shared with the red team, manage emergency stop/escalation, and accept red-team deliverables.
Red team	Receive only customer-approved handoff artifacts and return reports or attestations for hashing and retention.	Conduct testing with its own tooling, infrastructure, procedures, and approvals. Red-team execution is not performed in Stella.
Stella platform operator	Maintain Stella availability, signing keys, access controls, offline export path, and Evidence Locker retention configuration.	Does not make legal scope decisions or authorize offensive activity.
Competent authority/regulator	May receive signed evidence exports if the customer chooses to submit them.	Authority interaction, submission timing, and filing channel are customer-controlled.

2. Required Inputs

Before a TLPT scope is approved, the white team should collect and record:

Tenant identity and DORA relevance from the tenant compliance profile.
Critical or important functions that the customer expects to include.
Asset Registry v1 input for the tenant, using only host, container, image, service, integration, and plugin asset types.
ReachGraph subgraph reference or local ReachGraph input hash.
Criticality threshold for in-scope assets.
Exclusions, testing windows, emergency stop contacts, and legal approvals.
Retention policy selection for TLPT artifacts.

Current implementation note: the TLPT scoper accepts a local Asset Registry v1 JSON file and local ReachGraph input. Live Asset Registry queries are not yet the authority for this workflow. The input files used for scoping must be retained or content-addressed so the scope can be reproduced.

3. Artifact Register

Artifact	Produced by	Recipient	Minimum evidence fields
TLPT scope JSON (`tlpt-scope.v1`)	Stella TLPT Scoper, operated by the white team	White team; excerpt may go to red team	`scopeId`, `scopeHash`, tenant, included assets/functions, ReachGraph digest, validity window, warnings.
Baseline manifest	Replay TLPT baseline workflow when available; interim value may be caller-supplied	White team	Baseline hash, frozen timestamp, feed/policy/dependency graph state, scope hash binding.
Controls inventory	White team using Stella evidence sources	White team; optional regulator export	Control refs, owner refs, status at baseline, hash of exported inventory.
Red-team handoff memo	White team	Red team	Approved scope excerpt, rules of engagement reference, testing windows, exclusions, emergency stop contact, handoff hash.
Red-team receipt	Red team	White team	Received artifact hash, timestamp, receiver identity, channel used.
Post-test report or attestation	Red team	White team	Report hash, test window, red-team signer/attester, link to authorized scope.
TLPT evidence pack	Evidence Locker pack workflow when available	Customer/operator; regulator if requested	Scope hash, baseline hash, controls inventory hash, pre/post snapshots, sign-off, signer, retention setting.

Do not copy secrets, credential values, or expanded human PII into TLPT scope or handoff artifacts. Asset owners and credentials must remain opaque references.

4. Approval Gates

The customer should require explicit approvals at these gates:

Gate	Required approvers	Stella record
Scope draft accepted	TLPT sponsor, white-team lead, asset/function owners as required	Scope hash, approver identities, approval timestamp, unresolved warnings.
Baseline freeze	White-team lead, Stella platform owner, evidence owner	Baseline hash, scope hash, freeze timestamp, input hashes.
Red-team handoff	TLPT sponsor, white-team lead, legal/regulator liaison if required	Handoff memo hash, delivery channel, receiver, exclusions, emergency stop contact.
Post-test pack closure	White-team lead, remediation owner, evidence owner	Pack hash, red-team report hash, sign-off, retention setting.
Regulator submission	Customer-authorized approvers per tenant/channel	Export hash, signer, channel, submission receipt if one exists.

Auto-submission is not part of this TLPT runbook. If a future channel supports submission, it must remain tenant opt-in, require customer-configured approvers, and produce separate audit evidence.

5. Workflow

5.1 Prepare Scope Inputs

Confirm the tenant, LEI/jurisdiction data, and DORA TLPT significance outside this runbook.
Export or stage the local Asset Registry v1 input and ReachGraph input.
Select the criticality threshold and validity window.
Record any known data-quality gaps before generating scope.

If the scoper emits coverage warnings, the white team must either correct the input and regenerate scope or approve the warning explicitly. A scope with unreviewed warnings must not be handed to a red team.

5.2 Generate and Review TLPT Scope

Use the TLPT Scoper according to the TLPT Scoper module guide and the tlpt-scope.v1 contract. The same inputs must produce the same JSON bytes, scopeId, and scopeHash.

Review checklist:

Included assets match the approved criticality threshold.
Included business functions are complete enough for the planned TLPT.
Third-party dependencies are visible as direct assets or documented as operator-supplied facts.
ReachGraph digest matches the intended subgraph.
frozenBaselineHash is present, even if caller-supplied until the Replay TLPT baseline workflow lands.
Validity window covers the planned preparation and execution period.

5.3 Freeze Baseline Evidence

When the Replay TLPT baseline workflow is available, freeze feed, policy, dependency graph, and asset state at the approved baseline time and bind that baseline to the scope hash.

Until that workflow is available, the white team must record the caller-supplied frozenBaselineHash, the source of that hash, and the exact local input hashes used by the scoper. This is an interim evidence posture, not a substitute for a full replayable baseline.

5.4 Handoff to the Red Team

The white team, not Stella automation, decides what the red team receives. Recommended handoff contents:

Approved scope excerpt and scope hash.
Rules of engagement reference and authorization letter reference.
Testing windows, emergency stop contact, and escalation path.
Excluded systems, excluded techniques, and data-handling constraints.
Minimal asset/function context required by the approved exercise.
Offline verification material if the red team needs to verify signatures.

Forbidden handoff contents from Stella by default:

Stella administrator credentials or signing keys.
Secret values, credential material, or expanded human PII.
Exploit payloads, phishing kits, command-and-control configuration, or attack automation.
Unapproved full asset inventory beyond the TLPT scope.

The red team should acknowledge receipt with the handoff hash, timestamp, receiver identity, and delivery channel. Store that receipt as evidence.

5.5 During Test Execution

Stella may continue to preserve evidence-side state during the exercise:

Monitor evidence integrity and signing health.
Record emergency-stop decisions and operator interventions.
Capture defensive control snapshots if the customer approves.
Preserve chain-of-custody for any reports or attestations returned by the red team.

Stella must not direct attacks, generate payloads, manage red-team infrastructure, or provide an execution console for offensive activity.

5.6 Close the Evidence Pack

After the red-team phase, the white team attaches the red-team report or attestation by hash, records remediation ownership, and assembles the final TLPT evidence pack when the Evidence Locker pack workflow is available.

The final pack should bind:

Approved TLPT scope hash.
Baseline manifest hash.
Controls inventory hash.
Pre-test and post-test snapshot hashes.
Red-team report or attestation hash.
White-team sign-off and customer/operator approval.
Retention setting and signer identity.

The customer/operator decides whether to submit the pack, an excerpt, or a separate regulator envelope to a competent authority.

6. Retention and Overrides

Default expectation: retain TLPT evidence packs for 10 years. This covers three 3-year TLPT cycles plus audit lookback, matching the Evidence Locker TLPT pack sprint direction.

Customer/operator override rules:

The effective retention period is tenant policy and must be approved by the customer/operator.
Shortening retention below the default requires customer legal/compliance approval and an audit record.
Retention must not be shortened below an already-committed regulatory, contractual, or litigation-hold period.
Deletion must be content-addressed and logged by pack hash, scope hash, and approver.

The retention setting must travel with the final pack metadata so an offline auditor can determine the intended preservation period without querying a live Stella service.

7. Offline Evidence Flow

TLPT evidence workflows must work without external network access.

Recommended offline flow:

Generate scope from local Asset Registry v1 and ReachGraph inputs.
Record SHA-256 hashes of every local input file.
Freeze or record the baseline hash.
Export signed artifacts and trust roots to operator-controlled storage.
Transfer artifacts using the customer’s approved media and chain-of-custody procedure.
Verify signatures and hashes in the receiving environment.
Record verification output and retain it with the TLPT pack.

No live regulator endpoint, live schema fetch, SaaS dependency, or external threat-intelligence fetch is required by this runbook. If an operator chooses to submit or share artifacts externally, that is a customer-controlled action and should produce a separate delivery receipt.

8. Evidence Quality Checks

Before the runbook is considered complete for a TLPT cycle, verify:

Scope JSON validates against tlpt-scope.v1.
Scope hash in every downstream artifact matches the approved scope.
Baseline hash is present and source is documented.
Red-team handoff receipt hash matches the delivered handoff memo.
Red-team report or attestation is hashed before being attached to the pack.
Pack signer and retention setting are recorded.
Offline verification succeeds using only exported trust material.
Any warning, exclusion, or override has an approver and reason.

9. Escalation

Condition	Action
Scope includes unauthorized assets	Stop handoff, regenerate scope, re-approve.
Scope warnings are unreviewed	Block baseline freeze until warnings are resolved or approved.
Baseline hash cannot be reproduced	Mark the TLPT evidence pack incomplete and escalate to Replay/Evidence owners.
Red-team requests offensive support from Stella	Decline inside Stella scope; route to customer TLPT sponsor outside the product.
Retention override conflicts with policy	Block closure until customer legal/compliance approval is recorded.
Offline verification fails	Treat the artifact as untrusted; re-export or re-sign from the source environment.

10. References

DORA gap-closure plan — section D3.
EU decisions log — DORA-Q4.
tlpt-scope.v1 contract.
TLPT Scoper module guide.
EU compliance sprint execution directions.

Revision History

Version	Date	Author	Changes
0.1.0	2026-04-30	Documentation	Initial DORA TLPT white-team/evidence-side runbook.