Which NIS2 asset inventory requirements a Backstage catalog helps meet
If your organization is an in-scope entity under NIS2, you need an asset inventory that is kept up to date and records how it has changed. Point 12.4.3 of Annex to Commission Implementing Regulation (EU) 2024/2690 requires entities to regularly review and update the inventory and document the history of changes. ENISA's June 2025 technical implementation guidance for that regulation names an up-to-date inventory with change history, inventory metrics and the configuration of any inventory tool as examples of evidence. A Backstage catalog can supply much of this for services and software components, which are the entities it models best. It will not, on its own, cover hardware, network devices or data assets, and you should plan separate sources for those.
Be clear about what the catalog does and does not settle. NIS2 is a directive, so obligations reach you through your national transposition law, and it creates no certificate of compliance. National competent authorities supervise through inspections, security audits, security scans, information requests and administrative fines. Confirm with your national authority or legal counsel which entities in your group are in scope and how your transposition law expects inventory evidence to be presented. DeployOpen plans and builds the catalog, the Git and pipeline sources behind it and the evidence exports, and prepares that evidence for review. DeployOpen does not issue audit reports, attestations or certifications, and independent assessors or your authority decide whether your controls meet the requirement.
Start by mapping each requirement to a source you can show. For services and software components, the catalog entity is the record and its owner, lifecycle and system fields are the attributes. For change history, the Git repository behind each descriptor is the record of when and by whom the entry changed, so the catalog and Git must stay linked. Decide early who reviews the inventory, how often, and how a review is recorded, because that review is the evidence an assessor asks for first. Ask your implementation partner to show how each ENISA evidence example is produced, and which items remain manual.
Mapping point 12.4 and ENISA evidence to catalog features
This table maps the point 12.4.3 review and change-history requirement and the ENISA evidence examples to Software Catalog entities, Git-derived history, annotations and the configuration each one needs. Read the Coverage column first: rows marked partial need work outside the catalog, such as a separate asset register or a reviewed inventory process. The main takeaway is that the catalog covers software and service inventory well, but hardware, data and review evidence need additional sources.
| Requirement or evidence | Catalog feature and configuration | Coverage |
|---|---|---|
| Point 12.4.3: regular review and update of the inventory | Catalog entities with a required owner and a review annotation, plus a scheduled check that flags entities not updated within your review interval | Partial: the catalog holds the data, but the review itself is a documented human process |
| Point 12.4.3: documented history of changes | Git commit history of each catalog-info.yaml file, read through the Git provider and the catalog's source location | Partial: history covers descriptor edits only, not runtime or infrastructure changes |
| ENISA: inventory documentation | Entity descriptors, a documented field standard, and a written procedure describing how entities are created and retired | Covered when the descriptor standard is written and enforced through templates |
| ENISA: up-to-date inventory with change history | Catalog ingestion from Git providers on a schedule, with entity locations kept in source control | Partial: depends on ingestion health and on owners keeping descriptors current |
| ENISA: inventory metrics | Catalog counts by system, owner and lifecycle, produced with the catalog API or a scheduled report | Partial: Backstage does not ship a compliance metrics dashboard; confirm the report design with your team |
| ENISA: configuration of the inventory tool | Versioned app-config files, plugin configuration and the list of enabled entity providers, stored in Git with change review | Covered when configuration is kept in source control and deployed through the normal pipeline |
| Classification of assets | Custom annotations or tags for classification level and supporting system type, defined in your entity schema | Partial: annotations must be defined and validated by you; Backstage does not classify assets itself |
| Hardware and physical assets | Not a native catalog focus; a Resource entity can point to an external CMDB or asset register | Gap: plan a separate source of truth and link to it |
What evidence the catalog produces for NIS2 auditors
The catalog gives an auditor several records that can be tested independently: the descriptors themselves, the Git history behind them, the catalog configuration and the coverage metrics. Each one answers a different question about whether the inventory is current, complete and controlled, and each needs a defined owner and retention rule.
Exported descriptor YAML
The catalog-info.yaml files in each repository are the entity records the portal ingests. Export them as a point-in-time set on a fixed schedule, so the inventory an auditor reviews can be reproduced for a given date. Check that each exported file carries the owner, lifecycle, system and classification annotations your NIS2 scope requires. Confirm with your team which branch is treated as authoritative, since the portal only reflects what the ingestion source reads.
Git commit history for changes
Git history is the change log for the inventory. Every edit to a descriptor is a commit with an author, timestamp and reviewer if branch protection requires review. Auditors can use this to test requirement 12.4.3's expectation that the inventory is reviewed and its changes documented. Confirm that the Git platform retains history without rewrites, and that force-pushes to protected branches are disabled.
Ownership and lifecycle fields
Owner, lifecycle and system fields show who is accountable for each asset and whether it is in production, experimental or deprecated. Auditors often sample these fields to see whether every in-scope system has a named owner who can answer questions. Define which values are allowed, who approves changes to ownership, and how entities whose owner has left are flagged for reassignment.
Catalog configuration as evidence
The catalog configuration shows which sources feed the inventory, which processors transform descriptors and what rules govern ingestion. Keep the configuration files under version control with the same review rules as application code. Record who changed the configuration and when, because a change to an ingestion rule can silently remove assets from the inventory. Confirm the configuration does not contain credentials, since it will be shared with assessors.
Inventory coverage metrics
Coverage compares the components registered in the catalog with the systems your organization operates. Track the share of in-scope systems with a descriptor, the number of entities without an owner and the count of stale entities that have not changed within your review interval. Store these figures with dates so the trend over time is visible. The metric is only meaningful if the denominator is a list of systems maintained outside the catalog.
Versioning and retention of records
Tag each quarterly export and the configuration revision it used, then store them in a repository or archive your compliance team controls, separate from the portal database. Set a retention period that matches the requirements your national authority or internal policy specifies, and confirm it with your legal team, since no retention period is given in the regulation for this record. Restrict write access so that archived evidence cannot be altered after the fact.
How service, system and dependency records fit together in the catalog
The inventory is only traceable if the catalog links every service to the systems it runs on and the owners who answer for it, so start by settling that model before any data is loaded. In Backstage, a Component describes a service, website or library, a System groups components and resources that work together, a Resource describes supporting infrastructure such as a database, bucket or queue, and a Domain groups systems around a business function. Each component should point to its system with spec.system, and each resource should be attached to the component that uses it. Ownership is set with spec.owner, which names a Group or User entity, so an auditor can follow a record to a person or team who must review it.
Dependencies are where the inventory becomes testable. The spec.dependsOn field on components and systems lists the entities a record relies on, and the catalog builds the reverse view, so a reviewer can ask which services depend on a given database and see the answer without a spreadsheet. Decide which relations are mandatory for an in-scope service (for example, every component must name a system, an owner and every database it writes to) and encode that rule in your descriptor review or a catalog check. Confirm with your supervisory authority or legal adviser how far the NIS2 national transposition in your Member State expects supporting systems, such as identity or logging services, to be recorded as separate entities.
Not everything should come from source. Ownership, system membership, classification and business criticality are decisions a person makes, so these belong in descriptors that teams maintain in their own repositories and that are reviewed through pull requests. Facts that a machine can observe, such as repository location, CI pipeline, deployment target or the Git history of the descriptor, should be ingested through a source integration so they cannot drift. Classification must be carried in annotations or tags that your organization defines (for example, an annotation naming a criticality tier and the NIS2 sector), and the allowed values should be fixed in a short written standard so that each entity's value can be explained to an auditor. Check that the plugins you rely on read those keys as you intend before treating them as evidence.
What the catalog does not cover for NIS2
The Backstage catalog describes software, services and the teams that own them, but NIS2 inventory evidence also reaches hardware, data, cloud accounts and operational facts. Each gap below needs either another source of record or a documented process owned by named people.
Physical hardware and network devices
Servers, firewalls, switches, load balancers and out-of-band management controllers usually live in a CMDB, a DCIM tool or a network management system, not in Git. A Backstage Resource entity can point to a rack-mounted host or a cluster node, but nothing in the catalog discovers it. Confirm with your operations team which hardware sits in scope for the entity and where its serial numbers, locations and lifecycle dates are recorded.
Data assets and their classification
The catalog can label a component as holding confidential data, but it does not inventory the datasets, databases, file shares or backups themselves. Classification levels also need a policy source outside Backstage. Confirm which data stores each service writes to, who owns each dataset, and whether the classification scheme used in annotations matches the one your information security policy defines.
Cloud accounts not represented as entities
Cloud subscriptions, projects, accounts and their IAM bindings often exist without a matching catalog entry, especially sandbox or legacy accounts. Unregistered accounts can host in-scope systems that no inventory lists. Compare the cloud provider's account list against catalog Resource entities and record the accounts that carry no catalog owner as explicit gaps.
Shadow systems outside Git
Systems deployed by hand, SaaS tools bought on a corporate card, and scripts run from a laptop never pass through a template or a repository. The catalog only sees what someone registers. Ask each business unit for its software list, check identity provider application registrations and expense data, and decide how unregistered systems enter the inventory and how long they can remain outside it.
Operational fields such as RTO and RPO
The catalog schema has no native fields for recovery time objectives, recovery point objectives, criticality ratings or maintenance windows. You can carry them as custom annotations, but they must be filled and reviewed like any other data. Confirm the values with business owners and the backup team, and check whether your NIS2 scope requires them in the inventory or in a separate continuity record.
An inventory process owned by people
Catalog data stays accurate only when named people review it on a schedule and act on what they find. Ownership, review cadence, escalation for stale entries and sign-off of changes are decisions made by the organization, not features of the tool. Confirm who approves inventory changes, how often the review happens, and where the review record is kept so that an authority can see it.
Configuring the catalog as a NIS2 inventory source
This sequence turns the Backstage catalog into an inventory that names what is in scope, who owns it, how it is classified, and how it is reviewed and exported as evidence for point 12.4.3 of Implementing Regulation 2024/2690.
Define the in-scope asset boundary
Start with your compliance lead and the team responsible for the NIS2 risk-management measures to decide which services, supporting systems and infrastructure fall within the regulation's scope for your entity. Record the boundary as a written list of systems and the business services they support. Confirm with counsel or your national competent authority guidance where the scope is unclear. Done when every in-scope system has a named candidate catalog entity and any excluded system has a recorded reason.
Agree the descriptor schema and classification annotations
Define the minimum fields each catalog descriptor must carry for an inventory entry, such as the system type, business service, data sensitivity, hosting location and dependencies. Map each field to the evidence ENISA's June 2025 guidance expects an inventory to show, and agree how classification is recorded in annotations. Keep the schema in version control so changes are reviewable. Done when a written schema is approved and a sample descriptor for one in-scope system validates against it.
Enable source-control ingestion for descriptors
Configure the catalog to discover descriptor files from the repositories where in-scope systems are maintained, so that the catalog reflects what lives in source control rather than manual entries. Confirm the ingestion method and its refresh behavior against the integration documentation for your source-control platform. Limit read access to the service account used for discovery. Done when a test change to a descriptor appears in the catalog and the ingestion log records the source commit.
Set ownership and lifecycle rules
Assign every in-scope entity an owner group and a lifecycle state, and define who may change either value. Owners are the people who answer for the asset during an inspection, so use team identities that exist in your identity directory rather than individuals who may leave. Decide how entities without an owner or with a retired lifecycle are reported. Done when a report lists all in-scope entities and none lacks an owner or lifecycle value.
Establish the review cadence for point 12.4.3
Point 12.4.3 requires entities to regularly review and update the asset inventory. Agree a written review cadence with the owners, assign a reviewer for each in-scope group, and record each review as a dated decision. Define what a review must check, including that owners, dependencies and classifications are still correct. Confirm the interval against your national transposition measures and your own risk assessment. Done when the first review is recorded with its date, reviewer and outcome.
Capture change history from Git
Because the catalog reflects descriptors in source control, the commit history of each descriptor serves as the change log for the inventory. Confirm that protected branches and required reviews apply to descriptor files, so that every change to an inventory entry has an author and an approver. Note where the Git platform cannot show who approved a change. Done when a sample inventory change can be traced from the catalog entry to its merged commit and review.
Export inventory evidence on a schedule
Set up a recurring export of the in-scope catalog entities, their owners, classifications and the last review record, and store each export with a timestamp in a location the compliance team controls. Keep the export tool configuration under change control, since ENISA lists the configuration of an inventory tool as evidence. Done when two consecutive scheduled exports exist and a reviewer can reproduce the entity count from the source system.
Questions buyers ask before using a Backstage catalog for NIS2
Does a Backstage catalog alone satisfy NIS2 point 12.4?
No. The catalog is a strong source for the inventory itself, but point 12.4 of Implementing Regulation (EU) 2024/2690 is about an inventory that is regularly reviewed and updated with a documented change history, and that is only one part of what an assessor looks for. The catalog can hold services, supporting systems, owners and classification annotations, and Git history can show how entries changed over time. Gaps usually remain for hardware, network devices, data stores managed outside code, and the review records themselves. Ask your national competent authority or legal adviser how they read the evidence expectations, and confirm with the ENISA technical guidance which evidence items your organization must produce.
What drives the effort of building a NIS2 inventory in Backstage?
The main drivers are the number of in-scope services, the number of repositories and how consistently teams already store service metadata, the design of your classification scheme, and the quality of any existing CMDB data. A catalog with a few hundred components across well-structured repositories is a different job from one spread across many unmanaged repositories with no ownership data. Classification design often takes longer than expected because it needs agreement from legal, risk and operations teams. Ask any provider to break the quote down by discovery, classification model, ingestion, reconciliation with existing records and evidence export.
How long does it take to get a usable inventory?
The time depends on how fast the team can agree what counts as an asset, how many sources must be connected, and how much existing data needs cleaning. Catalog ingestion from source control can start early, but a usable inventory also needs owners confirmed, classifications applied and gaps tracked. No fixed duration can be given without a written scope. Ask for a plan that separates a first pass covering known services from a complete inventory, and ask which milestones depend on your team's decisions rather than on implementation work.
What does the work need from our team?
Most of the effort on the client side is decision work. Your team needs to name accountable owners for systems and services, approve the classification fields, confirm which environments are in scope, and provide access to source control, identity and any existing asset registers. Someone must also own the review process after handover, since the regulation expects the inventory to be regularly reviewed. Engineers will need time to add or correct descriptor files in repositories. Ask the provider to list these inputs by name and role before work starts.
Can our own team build the NIS2 inventory without a consultant?
Yes, a capable platform team can deploy Backstage and load catalog data without outside help, provided it has engineers familiar with Backstage and the time to do it. The harder questions are compliance questions: which assets fall in scope, how to classify them, and what evidence an assessor will accept. Teams often underestimate the review and reconciliation work, and the portal needs to be maintained through Backstage upgrades. A partner can be used for the full build, for a fixed-scope piece such as the classification model, or for a readiness review of your own design. Decide which of these fits your capacity before you request a quote.
What should a consultant quote for a NIS2 catalog project include?
A useful quote states the scope in writing, including the systems and repositories covered, and lists deliverables such as the catalog model, classification annotations, ingestion configuration, evidence export and handover documentation. It should separate one-time work from recurring costs, such as hosting, Backstage upgrades and periodic reviews, and say which tasks depend on your team. It should also name exclusions, for example hardware inventory or data asset classification, and state the assumptions behind the timeline. DeployOpen works from a written scope and does not publish prices, so ask every provider for the same breakdown to compare them fairly.
Which Backstage components and settings matter for inventory evidence?
Engineers should focus on the software catalog, which records components, systems, resources and owners, and on the descriptor files that feed it. The catalog stores entities in a model that can carry classification annotations, so classification values should be defined in a shared convention before ingestion. Git history of descriptor files provides the change record, provided commits are reviewed and the repository is the source of truth. Authentication settings matter too, because the authentication documentation advises that sign-in resolves every provider to the same identity and that guest access is not offered in production. Check the configuration of the tool itself, since ENISA lists it as evidence.
What breaks most often in a catalog-based inventory?
The most common failures are stale entries, descriptor files that no longer match the running system, and ownership fields that point to people who left the organization. Ingestion can also silently skip repositories if discovery rules are too narrow, which creates gaps that look like completeness. Classification values drift when teams invent their own labels. Plan a recurring reconciliation job that compares the catalog with cloud accounts and source control, and record each exception with a reason and an owner so the review trail is complete.
What your team must own after the catalog is live
The catalog does not keep itself accurate, so your team must own four recurring tasks from the day it goes live: owner review, descriptor maintenance, Backstage upgrades and evidence retention. Each entity needs a named owner who reviews it on a fixed cycle, confirming that the spec.owner field, the spec.system link and the lifecycle value still describe reality. Decide who holds that role for each team, how reviews are recorded, and what happens to entities whose owner has left the organization. Entities without a live owner are the first gap a national authority or your own assessor will find.
Descriptor changes should move through pull requests in the source repositories, so that Git history becomes the change record for the inventory. Require review of catalog-info.yaml changes by someone other than the author, and treat changes to classification annotations as security-relevant. Your platform team should own the upgrade track as well. Choose a supported Backstage release line, follow the versioning policy, and plan to apply security fixes promptly, because the policy states that high and critical severity vulnerabilities will always be backported to releases from the last 6 months if feasible. Confirm the current support window with the vendor before you commit to a cadence, since an unpatched portal is itself an inventoried asset.
Finally, decide who answers a request from a national competent authority and where the evidence lives. NIS2 creates no certificate, so authorities test your records through inspections, information requests and scans, and ENISA's June 2025 guidance expects an up-to-date inventory with change history and the configuration of the inventory tool itself. Keep periodic exports of the catalog, the Git log for the descriptor repositories, the Backstage version and configuration files, and records of owner reviews, stored with retention rules set by your legal team. Confirm with your counsel how long your national transposition law expects these records to be kept.
How a DeployOpen engagement for this inventory is scoped
The sequence turns an open question about which systems count as in scope into a written scope, a configured catalog with evidence the team can export, and a handover the internal team can run without outside help. Each step closes with a named output so both sides can confirm progress.
Hold the scoping meeting with compliance and platform owners
DeployOpen meets the people who own the NIS2 obligations, the platform team that runs Backstage or will run it, and the owners of the source control and identity systems. The group confirms which entity and sectors are in scope, which services and supporting systems the inventory must cover, and which Git platforms and identity directories hold the data. Done when the group agrees a list of in-scope systems and names an owner for each source and for the inventory itself.
Review existing catalog and source data
DeployOpen inspects any existing Backstage instance, catalog descriptors, and the repositories and directories that would feed it, and compares them with the inventory fields the scope requires. The review shows which assets already have owners, lifecycle state and change history from Git, and which exist only in spreadsheets or other tools. The output is a gap list that separates data the catalog can hold from data that needs another system of record.
Agree the written scope and deliverables
DeployOpen writes down the scope, the deliverables, the assumptions about the client environment, and the responsibilities of each party before any build work starts. The document lists the classification annotations, the ingestion paths, the evidence outputs and the items deliberately left to other tools. Done when both parties sign the scope and the client confirms which open questions the scope depends on, such as access to source systems or the choice of hosting for Backstage.
Configure the catalog and ingestion paths
DeployOpen sets up the descriptor model, ownership and system relationships, classification annotations, and the providers that pull entities from Git and identity sources, all running in infrastructure the client controls. Configuration is tested against sample entities that the client supplies so that changes in source repositories appear in the catalog and removed assets are flagged rather than silently dropped. The step closes when a test run produces the expected entities and the client's reviewers accept the results.
Assemble the evidence pack
DeployOpen builds the exports, reports and documentation that show the inventory is maintained: the inventory documentation, the change history drawn from Git, the inventory metrics, and the recorded configuration of the catalog and its ingestion tools. The pack is organized against the points of Implementing Regulation 2024/2690 that the scope covers. Done when the client's compliance lead has reviewed a sample pack and confirmed it contains what their assessor will ask to see. DeployOpen does not issue any assessment or attestation.
Run the handover and document the operating routine
DeployOpen walks the platform and compliance teams through the configuration, the review cadence for the inventory, how to add or retire a system, and how to produce the evidence pack on request. The client receives written runbooks and a list of open items with owners. Done when the internal team performs one routine task, such as onboarding a new system or regenerating the evidence pack, without DeployOpen present.
How DeployOpen scopes and delivers NIS2 inventory configuration
DeployOpen plans, configures and documents the Backstage catalog so it can serve as an asset inventory for NIS2 review. Engagements start with a written scope that fixes which entities, sources and evidence outputs are in and out, before any configuration work begins.
How we scope
- Agree in writing which services, supporting systems and infrastructure resources the catalog must cover for your NIS2 scope.
- Confirm which entity fields, owners and classification annotations your reviewers need, and which ones must come from other systems.
- Record which Git repositories, CMDB or cloud accounts feed the catalog, and who approves each source.
How we build
- Configure the system model, ownership and classification annotations in descriptor files stored in Git under change control.
- Set up ingestion from your source control platform and test that each entity updates when its repository or descriptor changes.
- Check the catalog against a sample of real assets and document each gap, such as hardware or data assets the catalog does not hold.
How we hand over
- Deliver written configuration documentation, the descriptor standard, and a runbook for adding or retiring assets.
- Document how change history is read from Git and how the evidence export is produced and stored for reviewers.
- Walk your compliance and platform teams through the evidence set so they can explain it to competent authorities or auditors.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing.
- Review the inventory configuration when Backstage releases change the catalog, and plan upgrades with your platform team.
- Confirm with your legal and compliance advisers which NIS2 transposition rules in your Member State apply to your entity.
