Assurance Scope Model

This page defines the evidence-ownership and software-estate boundary for every Assurance pack: which evidence Stella Ops can produce or help package, and whose responsibility each evidence lane remains. It is the guardrail that keeps an Assurance pack from drifting into a blanket “compliant” claim. Read it alongside the Assurance Runtime architecture and the product-level Assurance and Compliance Packs entry point.

Stella Ops is a release control plane and DevOps vulnerability scanner, not a broad compliance suite. Assurance packs describe what evidence Stella can produce or help package, and whose responsibility each evidence lane remains.

Scope Lanes

Scope	Owner	Used for
`stella-product`	Stella	CRA product-security publication, CVD, support lifecycle, signed releases, SBOM/VEX, and product advisory evidence.
`stella-supplier`	Stella as supplier or ICT third party	Signed releases, SBOM/VEX, build attestations, advisory/CVD posture, security contact, lifecycle, and incident notification evidence reused by an operator.
`operator-observed-estate`	Operator, observed through Stella	Container images, release bundles, services, integrations, plugins, runtime host agents, asset registry entries, reachability, policy gates, and evidence bundles Stella deploys, scans, observes, or controls.
`operator-supplied`	Operator or product manufacturer	Legal entity facts, regulatory classification, governance policies, HR/training, physical security, contracts, subcontracting beyond direct integrations, risk acceptance, filing approvals, and competent-authority details.

Pack Application

Pack	Primary scope	Notes
NIS2 Evidence Pack	`operator-observed-estate`	Stella can support software-estate evidence for Article 21-style control mapping, SoA exports, incident timelines, and effectiveness metrics. Entity classification, governance ownership, physical security, HR, and process evidence remains `operator-supplied`.
DORA Operational Resilience Pack	`operator-observed-estate`	Stella can support ICT software evidence, RoI local-contract projection for observed integrations/assets, major-incident handoff facts, TLPT evidence packaging, retention, and Article 45 sharing batches. Financial-entity identity, contracts, outsourcing decisions, subcontracting beyond direct integrations, and filings remain `operator-supplied`.
CRA Product Security Pack	`stella-product`	Stella owns this product/security publication evidence for Stella itself.
CRA Technical Documentation Pack	`operator-supplied`	Stella assembles signed dossiers for a manufacturer; the product manufacturer supplies product identity, intended purpose, conformity route, and non-Stella product evidence.

Implementation Rules

NIS2 and DORA descriptors must include operator-observed-estate and operator-supplied; missing scope metadata blocks configured pack status.
UI, CLI, and exports must label operator-supplied gaps. They must not imply that Stella telemetry proves legal, HR, physical, contract, or filing facts.
CRA product-security evidence can feed stella-supplier when a customer uses Stella as a supplier, but that does not make Stella the customer’s regulated NIS2 entity or DORA financial entity.
Setup keeps Assurance packs optional. Enabling a pack configures evidence support and readiness workflows, not legal certification.
Runtime code must not fetch live regulator schemas, taxonomies, or external templates. Approved assets enter through offline asset intake and release review.

Software Estate Boundary

For NIS2/DORA, “software Stella can monitor or deploy” means:

container images and release bundles Stella promotes;
services and components in Stella’s asset registry;
integrations, plugins, and direct ICT providers represented in Stella inventory;
runtime host agents and observed runtime facts;
SBOM, VEX, reachability, policy, release, evidence-locker, and notification artifacts produced by Stella.

Anything outside that boundary is either operator-supplied or out of scope for Stella evidence.