How the Backstage catalog supports an ISO 27001 A.5.9 asset inventory
An ISMS owner preparing for an assessment needs an inventory of information assets with a named owner for each one. Control A.5.9 in ISO/IEC 27001:2022 covers that requirement. It merges the 2013 controls A.8.1.1 (inventory of assets) and A.8.1.2 (ownership of assets), and NIST's crosswalk relates it to CM-8, System Component Inventory. The Backstage Software Catalog can serve as the working record for the software and service part of that inventory: Component, API, System, Resource and Group entities, each with an owner field that points to a team or user. It does not cover the whole A.5.9 scope. Hardware, data assets, information classification, and recovery objectives such as RTO and RPO are not part of the default catalog model, so you will need a separate register or custom annotations for them. Confirm with your certification body how it expects those categories to be recorded.
The catalog is only useful as evidence if it stays current. Decide which source is authoritative for each entity type, then ingest from that source rather than maintaining entries by hand. Most teams use a catalog-info.yaml file in each repository, read through a Git integration, and treat a registration entry as the start of an ownership record, not a finished one. Schedule a review that compares catalog entries against your cloud accounts and deployment inventory, and record who approved each review. Retained snapshots, the Git history of descriptor files and the catalog's own API responses can then be exported as dated evidence for an auditor. Confirm your Backstage version and export method against the Backstage versioning policy before you rely on them.
DeployOpen plans and builds the catalog model, ingestion, review process and evidence exports, and prepares the records an assessment will examine. DeployOpen does not issue audit reports, attestations or certificates. Certification is granted by an accredited certification body that audits to ISO/IEC 17021-1 and ISO/IEC 27006-1, and each certificate runs on a three-year cycle with at least one audit every calendar year. Ask the certification body early which inventory fields and review intervals it will test, and set the catalog model against those requirements before the first assessment. For the control text itself, read ISO/IEC 27002:2022 for guidance, and do not treat the catalog as a substitute for your own asset register policy.
Mapping A.5.9 expectations to catalog capabilities and configuration
This table compares what an A.5.9 inventory expects with what the Backstage software catalog provides, the configuration each requirement needs, and what your team must still maintain by hand. Read each row as a question to put to your own Backstage version and environment. The main takeaway is that the catalog covers software and service records well, while hardware, data and reconciliation with the asset register remain your responsibility.
| Requirement | Backstage capability | Configuration needed | What remains manual |
|---|---|---|---|
| Inventory of information and associated assets (A.5.9, from A.8.1.1) | Software Catalog records components, APIs, systems and resources as entities defined in descriptor files | Define a Component, System or Resource entity for each in-scope asset and register it through a catalog location or provider | Deciding the asset scope, and adding hardware, network devices and data stores that have no catalog kind by default |
| Ownership of assets (A.5.9, from A.8.1.2) | Entities carry an owner field that references a Group or User entity | Set spec.owner on every entity, and map owners to a Group that reflects accountable teams | Confirming owners are accountable, not just listed, and handling owners who leave the organization |
| Asset grouping by system (context for A.5.9) | Systems group components, APIs and resources through the system relationship | Set spec.system on components and resources, and document the system model in the descriptor | Agreeing system boundaries with the business and keeping them current as architecture changes |
| Component inventory reference (NIST CM-8 crosswalk to A.5.9) | Catalog entities and their relationships describe deployed software and dependencies | Add dependsOn and dependencyOf relations and annotations that point to deployment or CMDB identifiers | Recording hardware, physical location and version details the catalog does not model natively |
| Currency of the inventory | Entities are ingested from source descriptors, so changes in the repository update the catalog on the next ingestion cycle | Keep descriptors in the owning repository, and configure ingestion schedules and orphan handling | Checking for entities removed from source, reviewing stale owners, and confirming ingestion is healthy |
| Asset attributes such as classification and criticality (Annex A attribute model) | Annotations and custom metadata fields can carry attribute values from the descriptor | Define a consistent annotation schema, and confirm the fields your assessor needs are stored and displayed | Assigning classification values and approving them under your information security policy |
| Evidence export for an assessor | Catalog content is available through the catalog API and the user interface | Document the query or API calls used, and retain dated exports with the descriptor commit reference | Assembling the evidence pack, and reconciling it with your separate asset register and auditor sampling |
What an auditor tests in an A.5.9 inventory
An auditor testing A.5.9 starts with a sample, not with your document. They pick assets from the inventory and check that each one is actually identified, that each has a named owner who is accountable for it, and that the record matches what exists in your environment. They then trace the inventory back to the scope of your information security management system, so they can see that the assets that matter to the ISMS are in the list and that the boundary you drew is reflected in it. A catalog that is well structured but out of date fails this test quickly, because a single missing system or an owner who has left the company is enough for a finding.
Annex A of ISO/IEC 27001:2022 lists 93 controls in four themes: organizational, people, physical and technological. A.5.9 sits in the organizational theme, and auditors read it alongside controls that depend on it, such as configuration, change and supplier management. The timing matters as much as the content. A management system certification cycle runs three years, with at least one audit in every calendar year, so the auditor will not see your inventory once and move on. Between audits, you need a process that keeps the record current as systems are added, changed and retired, and you should be able to show the change history that proves it. Confirm with your certification body how it plans to sample the inventory in each year of your cycle, and what it expects as evidence between visits.
Configuring the catalog so it can serve as an inventory
This sequence turns a default Backstage catalog into a set of entities with defined scope, named owners and resolved identities, so the catalog can be read as an asset inventory. The catalog model itself is covered on the software catalog pages, so this section focuses on the configuration decisions that make the data usable as evidence.
Define the asset scope in writing
Before any entity is registered, the GRC lead and the platform owner agree in writing which systems, services, data stores, hardware and third-party resources count as in-scope assets for the ISMS. The document should state which asset classes the Backstage catalog covers and which are tracked elsewhere, such as a CMDB or asset register. This closes when the scope statement is approved and linked from the inventory procedure, so an auditor can see what the inventory is meant to cover before reviewing the entities.
Choose the entity kinds for each asset class
Map each in-scope asset class to a Backstage entity kind: components for deployable software, APIs for interfaces, resources for infrastructure such as databases and buckets, systems to group related parts, and domains for business areas. Decide which kind is the record of truth for each class so the same asset is not registered twice under different kinds. The mapping is documented and reviewed by the team that owns the catalog. Done when every in-scope class has one agreed kind and the mapping is in the procedure.
Require an owner on every entity
Set the owner field as mandatory for every kind in scope, and pick a reference format that points to a group or user entity rather than free text. Ask the platform team to confirm how the catalog handles entities that arrive without an owner, since this decides whether ownership gaps are visible or silently accepted. The check is complete when a test entity without an owner is rejected or flagged, and the team can run a query that lists owner-less entities.
Connect source control so owners resolve
Configure the catalog to read ownership and group data from your identity directory or the source control platform, so that the owner references resolve to real groups and people. Confirm with your identity team which directory source is authoritative and how group membership is refreshed. The step is complete when a sample entity's owner shows the correct group in the catalog and the same group exists in the directory, with no orphaned references.
Set sign-in resolvers for one identity per person
Configure the sign-in resolvers so that each identity provider resolves a person to the same catalog user. The Backstage authentication documentation advises this so that a person signing in with different providers does not appear as several users. Document which claim or attribute is the stable key and test it with at least one account that uses two providers. The step closes when the test account resolves to one user entity and the resolver rule is recorded with the access procedure.
Disable guest access in production
Turn off guest sign-in in the production configuration, as the Backstage authentication documentation advises, so every catalog change and every view of owner data is tied to an authenticated identity. Keep guest access only in local development configuration, and confirm that the production config file does not enable it through an environment override. The check is a sign-in attempt from an unauthenticated session that is refused, plus a review of the deployed configuration.
Confirm the sequence with a sample review
Run a dry review on a sample of entities from each in-scope kind. The reviewer checks that each entity has a valid owner, a sign-in identity matches the owner's directory record, and the entity matches the scope document. Record any gaps and assign them to owners with a tracked item. This review produces the baseline evidence that the configuration works as designed, and it should be repeated after configuration changes.
Evidence the catalog produces and how to keep it
The catalog can supply several records an auditor will ask to see for A.5.9, but none of them is an audit report or proves the inventory is complete. Each card below is an input you assemble, date and retain, and the set only holds up if the same owners review it on a fixed cadence.
Dated export of entities
Export the catalog's component, resource, system and API entities with their owner, lifecycle and system fields on a fixed date, and store the file outside the portal. An auditor tests whether the inventory existed on a stated date and whether each row names an accountable owner. Check that the export includes entities that have no owner, because those rows show where the inventory is weakest.
Git history of descriptor files
Descriptor files live in source control, so their commit history records when an asset was added, changed or retired and who approved the change. This history is strong evidence of change over time, but it covers only what has a descriptor. Confirm that retired assets are removed through a reviewed commit rather than deleted silently from the catalog database.
Sign-in resolver and access configuration
Show who could edit inventory records by documenting the sign-in resolver, the identity provider each user signs in with, and the permissions that allow catalog writes. Guest access in production would weaken this evidence, so confirm it is disabled. Record the configuration version that was in force for each period under review.
Backstage upgrade record
Record the Backstage version running when each export was taken, along with the Node.js version and the upgrade commits applied. Security fixes and version changes can alter how the catalog behaves, so an auditor may ask which release produced a given record. Keep the release notes for each upgrade alongside the export.
Owner review sign-off cadence
Set a recurring review in which each owner confirms their systems, dependencies and resources are still correct, and record the sign-off with a name and date. The cadence you choose should match the review interval in your ISMS procedures. Without signed reviews, the export shows only that records existed, not that anyone checked them.
Retained snapshots
Keep dated snapshots of the export, the descriptor commit reference and the signed review together in one evidence location with a stated retention period. Ask your compliance lead and the certification body which period they expect for ISMS records. Snapshots taken at the same time as each review let you reconstruct the inventory for any past audit window.
Keeping the inventory current from source
An A.5.9 inventory stays accurate only if its entries come from the systems where changes happen, not from someone retyping them. Keep a catalog-info.yaml descriptor in each repository, register it through your source control integration, and treat the catalog UI as a read view. When a service changes owner in its descriptor, the catalog follows on the next ingestion cycle, and the change is traceable in Git history, which is the evidence an auditor will ask for. Confirm with your platform team which entity providers and processors run in your deployment and how often they refresh, because that interval sets the lag between a real change and the record. Manual edits to ingested entities are typically overwritten on refresh, so decide before the first audit sample where corrections must be made.
Your ISMS should state how often owners confirm their entries, who performs the confirmation, and what happens when no one responds. Record each confirmation as an action with a reviewer and a date in your ISMS tool, rather than as a silent timestamp in the catalog. The reviewer checks that the person or group in spec.owner still holds that responsibility. The interval is an organizational decision, so document it and then follow it. Entities whose owners leave need a defined path: reassign them to a named team group, keep them visible until the new owner accepts, and log the handover so the ownership history can be shown to an auditor.
Patching affects the inventory too, because an unpatched portal is part of the environment you are declaring. Move all @backstage packages together with yarn backstage-cli versions:bump, then use the Backstage Upgrade Helper to review template changes between versions. The project's versioning policy says high and critical severity vulnerabilities will always be backported to releases from the last six months where feasible, and other security fixes may be backported, so the release line you run determines how quickly fixes reach you. Confirm which line your instance is on, check Node.js support before each bump, schedule a regular upgrade window, and record every upgrade in the change log that supports your A.5.9 evidence. The keeping Backstage updated guide is the natural starting point for the procedure.
Questions buyers ask before using the catalog for A.5.9
Does a Backstage catalog alone pass an ISO 27001 audit for A.5.9?
No. The catalog is one input to an A.5.9 inventory, not the inventory itself. An auditor will look for a documented inventory of information and associated assets, a named owner for each asset, and evidence that the inventory is kept current and reviewed. The catalog can hold software components, services, APIs and resources with owners, but hardware, data stores outside software, cloud accounts, endpoints and paper or contractual records usually sit outside it. Your ISMS documentation must explain what the catalog covers, where other registers live, and how the pieces reconcile. Confirm the exact evidence expectations with your certification body, since they decide how they test it.
What does a partner add to a catalog-based A.5.9 inventory, and what drives the effort?
A partner typically designs the descriptor model, defines which asset classes belong in the catalog and which belong in other registers, writes ownership rules, sets up ingestion from source control and cloud or CMDB data, and produces the evidence export. Effort is driven by the number of source systems, how much of the estate is already described in code, how many owners must be confirmed by people rather than inferred, the number of asset classes outside the catalog, and how well your ISMS documents already define scope. Ask any quote to list each source, each asset class, and each reconciliation step as a separate line.
What does the work need from our own team?
Most of the effort sits with your people, not the partner. You need an accountable owner for the inventory, system or service owners who can confirm what they run, platform engineers who control the source repositories and discovery sources, and someone from information security who defines the classification and review rules. Owner confirmation is often the slowest step because it requires a decision, not just data. Plan for these people to review draft entries, approve the owner model, and sign off on the review cycle your ISMS states.
Can an internal team build an A.5.9 inventory on Backstage without a partner?
Yes, if the team has Backstage experience, time for catalog design, and an information security lead who can translate the Annex A control into rules. The skills that are hard to staff internally are a clear descriptor model, ingestion that keeps entries current from source, and an export that auditors can follow. A useful test is whether your team can explain, for any entry, where it came from, who owns it, when it was last confirmed and what happens when it goes stale. If those answers are not already defined, a short scoping exercise will show whether the gap is design work or only build work.
How long does a catalog-based A.5.9 inventory take to set up?
Duration depends on the number of source systems, the number of asset classes you bring into scope, the state of ownership data, and how many reconciliation cycles your ISMS needs before audit. Systems with clean repository metadata and named owners move faster than estates where ownership must be confirmed manually across teams. No duration is fixed by the standard or by the tooling. Ask for a timeline tied to written milestones: scope agreed, model approved, sources ingested, owners confirmed, first review completed and evidence export tested. Timelines should be confirmed against your own environment before commitments are made.
How should hardware and data assets be handled if the catalog does not cover them?
Keep them in a separate register and link to it. Hardware such as servers, network devices, endpoints and removable media is usually held in a CMDB, an IT service management tool or an asset register that your infrastructure team already maintains. Data assets such as databases, file shares and classified datasets need their own classification and owner records. In Backstage, you can represent systems and resources that depend on this hardware or data, and reference the external register by identifier so that an auditor can trace from a service to the physical or data asset. Confirm with your certification body how they expect the cross-references to be evidenced.
How DeployOpen scopes and delivers the inventory work
DeployOpen approaches the Backstage catalog as an ISO 27001 A.5.9 inventory by first agreeing in writing which systems, owners and resources the catalog will cover, then building the descriptors, ingestion and evidence exports that keep that data current. Deliverables are fixed in advance, and the gaps the catalog cannot fill are documented alongside the rest.
How we scope
- Engagements are fixed-scope, with the inventory boundary, entity types and owner fields agreed in writing before work starts.
- The written scope names which asset classes the catalog covers and which hardware and data records stay in other registers.
- Ongoing support for the inventory can be arranged as a retainer after the initial delivery is accepted.
How we build
- Descriptor files, ownership rules and ingestion from your source control platform are built and tested against your own repositories.
- Annotations for classification and gap fields are defined and checked with a sample of entities before wider rollout.
- Evidence exports are scripted so the same inventory snapshot can be reproduced for an auditor on request.
How we hand over
- Handover includes the descriptor standard, ingestion configuration, runbooks and a written list of known inventory gaps.
- Your team receives the export procedure and a worked example of an evidence package mapped to A.5.9 wording in plain terms.
- Staff are walked through owner review tasks so inventory upkeep has a named process after the engagement closes.
How we support
- Support covers catalog ingestion failures, descriptor drift and changes to the Backstage release line your team runs.
- Retainers can include periodic owner review cycles and checks that new repositories register with a valid owner.
- Confirm with DeployOpen during scoping which upgrade and review responsibilities sit with your team and which sit with us.
