How Backstage Helps You Pass a NIS2 Audit

We published our NIS2 for Platform Teams guide last year. The most common follow-up question from CTOs and platform leads has been practical: "We understand the requirements. What tooling actually helps us meet them?"

The answer is not a single product. NIS2 compliance is a combination of processes, documentation, tooling, and operational discipline. But one component shows up repeatedly as the connective tissue that makes audit responses fast and verifiable: Backstage.

Not because Backstage is a security tool. It is not. But because the questions auditors ask — who owns this, what does it depend on, who can access it — are fundamentally catalogue questions. And a well-maintained service catalogue turns hours of scrambling into seconds of querying.

This article maps specific NIS2 audit requirements to specific Backstage capabilities. Where Backstage helps, we say so. Where it does not, we say that too.

What auditors actually ask

If you have not been through a NIS2 audit yet, it helps to understand what happens in practice. Auditors do not walk in with a checklist of abstract policy requirements. They ask your platform team to demonstrate things — live, on screen, with real data.

Here are the questions that trip up the most organisations, drawn from our experience with European platform teams preparing for and going through NIS2 assessments:

Access control:

• "Show me who has production cluster admin access right now." Not who should have access according to your policy document. Who actually does, today.
• "Show me the last time someone's access was reviewed and revoked."
• "Walk me through what happens when an engineer leaves. How quickly is access removed across all systems?"

Change management:

• "Show me the deployment pipeline for your production environment."
• "Pick a recent production change. Can you trace it from commit to deployment, including who approved it?"

Supply chain:

• "Show me your service dependency register."
• "For this service, what external providers does it depend on? Where is the data processed? Under which jurisdiction?"

Business continuity:

• "What is your recovery time objective for your core platform?"
• "What happens if your primary cloud region goes down?"

The common thread: auditors want to see living systems, not static documents. A PDF that someone wrote six months ago and has not updated since is not a convincing answer. A queryable catalogue that shows current state — and that teams actively maintain as part of their workflow — is.

Backstage as your service dependency register

NIS2 Article 21(2)(d) requires "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." In practice, this means you need a documented inventory of every service you run, every external dependency, and the relationships between them.

Most organisations attempt this with a spreadsheet. Someone on the platform team creates a Google Sheet with columns for service name, owner, dependencies, and provider jurisdiction. It is accurate for about three weeks. Then a team ships a new service without updating the sheet, someone changes a dependency without telling anyone, and the register drifts from reality. By the time the auditor arrives, the spreadsheet describes an infrastructure that no longer exists.

Backstage solves this structurally, not through discipline.

The software catalogue in Backstage is a registry of every component, service, API, and resource in your organisation. Each entity is defined in a YAML descriptor file (catalog-info.yaml) that lives alongside the source code in the service's repository. The team that owns the service owns the descriptor. When they add a dependency, they update the descriptor. When they change the API, they update the descriptor. The catalogue stays current because it is maintained by the people who know the truth — the teams doing the work.

A service entry in the catalogue can include:

• Owner: Which team is responsible. Not a name in a spreadsheet — a team entity in Backstage that links to real people.
• Dependencies: Which other services this one consumes. Expressed as relations between catalogue entities, so you can traverse the graph.
• APIs: What this service exposes and what it consumes. Defined as API entities with specifications (OpenAPI, gRPC, AsyncAPI).
• External dependencies: Cloud provider services, SaaS integrations, third-party APIs. Each can be modelled as a Resource entity with metadata about the provider and jurisdiction.
• Data classification: Custom metadata fields indicating what kind of data this service processes and where.
• Provider jurisdiction: Custom annotations documenting where the service and its dependencies are hosted, and under which legal framework.

When an auditor asks "show me your service dependency register," you open Backstage. You show them a live graph of services, their owners, and their dependencies. You click into any service and show them its external dependencies, data classification, and provider jurisdiction. You demonstrate that this information is version-controlled — every change to a catalog-info.yaml is a Git commit with an author, a timestamp, and a review trail.

This is qualitatively different from a spreadsheet. It is queryable. It is version-controlled. It is maintained by the teams closest to the truth. And it is auditable by design.

What the YAML looks like in practice

This is not abstract. Here is what a catalog-info.yaml looks like for a service with NIS2-relevant metadata:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  description: Processes customer payments
  annotations:
    backstage.io/techdocs-ref: dir:.
    nis2/data-classification: confidential
    nis2/provider-jurisdiction: EU (Frankfurt)
    nis2/recovery-time-objective: 4h
    nis2/last-risk-assessment: "2026-02-15"
spec:
  type: service
  lifecycle: production
  owner: team-payments
  providesApis:
    - payment-api
  consumesApis:
    - customer-api
    - billing-api
  dependsOn:
    - resource:default/postgresql-eu-west
    - resource:default/stripe-payment-gateway

The nis2/ annotations are custom. Backstage lets you define whatever metadata your organisation needs. The point is that this file lives in the same repository as the service code, is reviewed in the same pull request workflow, and is automatically ingested into the catalogue.

Backstage for ownership and access documentation

Every entity in Backstage has an owner. This is not optional — the catalogue schema requires it. When an auditor asks "who owns this service?" you answer in seconds, not hours.

This matters more than it might seem. In organisations with 50+ services, the question "who owns X?" can take surprisingly long to answer if the information lives in people's heads, Confluence pages, or a spreadsheet that predates three reorganisations. We have seen platform teams spend 30 minutes in an audit tracking down the owner of a service that turned out to be maintained by a team that was renamed twice.

Backstage solves this by making ownership a structural property of the catalogue. Every Component, API, and Resource has an owner. The owner is itself an entity — a Group or a User — so you can click through to see who is on that team and what else they own.

For access control documentation, Backstage is not the system of record — your identity provider is. But Backstage can surface access information in context. Plugins exist to integrate with identity providers (Okta, Azure AD, Keycloak) and display who has access to what, alongside the service they are looking at.

The Backstage RBAC plugin (available in both the community and commercial distributions) lets you visualise and manage permissions within the portal itself. More importantly for NIS2, it provides an auditable record of who can see and modify what within the developer portal — which is itself a system that auditors may ask about.

The practical workflow during an audit:

1. Auditor asks: "Who owns the payment service?"
2. You open Backstage, search for payment-service, show the owner: team-payments.
3. Click through to team-payments, see the members, their roles.
4. From the same page, show the other services this team owns.
5. Show the last changes to the service's catalogue entry — all in Git history.

Total time: under 60 seconds. Compare that to an organisation without a catalogue, where the answer involves checking three Confluence spaces, asking on Slack, and hoping someone remembers.

Backstage for SBOM and dependency scanning

NIS2's supply chain requirements extend beyond infrastructure dependencies to software dependencies. Article 21(2)(d) combined with ENISA's implementing guidance means that auditors increasingly expect Software Bill of Materials (SBOM) documentation and evidence of dependency vulnerability management.

Backstage does not generate SBOMs. But it serves as the integration point where SBOM data becomes accessible and actionable.

TechDocs for compliance documentation. Backstage's TechDocs feature renders Markdown documentation stored alongside your code directly in the portal. For NIS2, this means you can maintain compliance-relevant documentation — risk assessments, data processing records, recovery procedures — as code, reviewed through pull requests, and accessible through the same interface where teams find everything else about a service. Documentation that lives where developers already work actually gets read and updated. Documentation in a separate compliance tool does not.

Security plugin ecosystem. The Backstage plugin ecosystem includes integrations with dependency scanning tools that your platform team likely already runs:

• Snyk plugin: Surfaces vulnerability findings per service directly in the catalogue.
• Dependabot/Renovate integration: Shows dependency update status alongside service metadata.
• Security scorecard plugins: Aggregate security posture metrics (dependency freshness, known vulnerabilities, scan coverage) per service and per team.
• SBOM plugins: Display generated SBOMs (from tools like Syft or Trivy) within the service's Backstage page.

The pattern here is consistent: Backstage does not replace your security tooling. It aggregates the outputs and makes them discoverable in context. When an auditor asks about vulnerability management for a specific service, you can show scanning results, dependency status, and SBOM data from the same page that shows ownership and dependencies.

This matters for audit efficiency. Auditors do not want to log into five different tools to assess one service. A single interface that shows ownership, dependencies, security posture, and documentation for each service makes the audit faster and more thorough — which works in your favour.

What Backstage does not solve

This is the section that matters most, because adopting Backstage and believing your NIS2 compliance is handled would be a dangerous mistake.

Backstage is a catalogue, not a security tool. It documents who has access. It does not enforce access controls. It shows dependencies. It does not scan them for vulnerabilities. It surfaces security findings from other tools. It does not generate those findings. The distinction is critical.

Backstage does not detect incidents. When something goes wrong at 3 AM, Backstage provides context — who owns the affected service, what it depends on, who to call. That is valuable during incident response. But it is not your monitoring, alerting, or SIEM system. You still need Prometheus for metrics, a log aggregation stack, and a security event pipeline. Backstage tells you what you are looking at. Your observability stack tells you something is wrong.

Backstage does not enforce change management. It can display deployment history and link to CI/CD pipelines, but the actual controls — branch protection, required reviews, deployment gates — live in your Git platform and your CD tooling (Flux, ArgoCD). Backstage shows you the audit trail. Your CI/CD pipeline creates it.

Backstage does not prove business continuity. You can document RTOs and recovery procedures in TechDocs. You can annotate services with their recovery classifications. But Backstage cannot test your disaster recovery, validate your backups, or failover your services. Those are operational capabilities that require separate investment.

Backstage requires sustained investment. As we detailed in our Building an IDP from Open Source article, Backstage is a framework, not a product. Getting it to a state where it actually helps during an audit — catalogue populated, plugins configured, documentation templates in place, teams actively maintaining their entries — takes 4-8 weeks of dedicated engineering time for initial setup, and 0.25-0.5 FTE for ongoing maintenance.

If you deploy Backstage, populate the catalogue once, and then let it drift for six months, you will be worse off than having no catalogue at all. An auditor who sees a stale Backstage instance will rightly question whether any of your documentation is current. A catalogue that shows "last updated 8 months ago" on half its entries actively undermines your compliance posture.

To be direct: Backstage is one component in a NIS2 compliance toolkit. A valuable one, but not the whole answer. You still need:

• Observability (Grafana stack, Prometheus, Loki) for detection and investigation
• SIEM or security event pipeline for incident detection and correlation
• Identity provider (Keycloak, Okta, Azure AD) for access control enforcement
• GitOps tooling (Flux, ArgoCD) for auditable change management
• Backup and DR tooling for business continuity
• Vulnerability scanning (Trivy, Snyk, Grype) for supply chain security

Backstage ties these together. It is the index, not the library.

Practical setup: a minimal NIS2-ready Backstage configuration

If you are setting up Backstage with NIS2 compliance as an explicit goal, here is what a minimal viable configuration looks like. This is not the full developer portal experience — it is the subset that directly supports audit readiness.

1. Service catalogue with NIS2 metadata

Define a catalogue entity schema that includes the metadata auditors will ask about:

• Owner (required by default)
• Lifecycle stage (production, staging, deprecated)
• Data classification (custom annotation)
• Provider jurisdiction (custom annotation)
• Recovery time objective (custom annotation)
• External dependencies modelled as Resource entities with provider and jurisdiction metadata

Establish a convention that every production service has a catalog-info.yaml with these fields populated. Enforce it through CI — a pipeline check that fails if a production service lacks required NIS2 annotations. Automation beats discipline every time.

2. TechDocs with compliance templates

Create TechDocs templates for:

• Service risk assessment: What data does this service process? What are the threats? What mitigations are in place?
• Recovery procedure: How do you restore this service from backup? What is the expected recovery time? When was this last tested?
• Incident response context: During an incident involving this service, what are the first diagnostic steps? Who should be contacted?

Store these as Markdown files alongside the service code. Render them in Backstage via TechDocs. Teams fill in the templates as part of their service onboarding process.

3. Identity provider integration

Connect Backstage authentication to your organisation's identity provider. This accomplishes two things:

• Users in Backstage correspond to real identities in your directory, which means ownership data in the catalogue maps to real people.
• Backstage itself has an auditable authentication trail — who accessed the portal, when, and what they viewed.

4. API catalogue for external dependencies

Model external service dependencies as first-class entities in the catalogue. Every SaaS integration, every third-party API, every cloud-managed service should be a Resource entity with:

• Provider name
• Jurisdiction (headquarters and data processing location)
• Data access level (what can this provider see?)
• Contract expiry date
• Link to data processing agreement

This is the supply chain register that auditors will ask for. Building it in the Backstage catalogue — rather than in a standalone spreadsheet — means it is linked to the services that depend on it. When an auditor picks a service and asks "what third-party providers does this depend on?", you can traverse the dependency graph and show them.

5. Security plugin integration

At minimum, install and configure:

• A vulnerability scanning plugin that shows findings per service
• A dependency freshness tracker
• An SBOM display plugin if your build pipeline generates SBOMs

These do not need to be sophisticated on day one. The point is that security posture data is visible in the same place as ownership and dependency data, so auditors can assess a service holistically from a single interface.

The audit scenario

Here is what a good NIS2 audit interaction looks like when you have Backstage set up properly:

Auditor: "Show me your service dependency register."

You open Backstage. You show the full catalogue — 47 services, 12 APIs, 23 external resources. You filter by lifecycle: production. 31 services. You click one. You show its dependencies, its owner, its data classification, its provider jurisdiction. You show that the catalogue entry was last updated three days ago as part of a pull request that added a new dependency.

Auditor: "Who owns this service, and who has production access?"

You click the owner: team-platform. You show the team members. You click through to the identity provider integration showing current access grants. You demonstrate that access was last reviewed two weeks ago.

Auditor: "Show me the deployment pipeline and trace a recent change."

You click the CI/CD plugin tab. You show the last ten deployments, each linked to a Git commit. You click one, it opens the merge request in GitLab — author, reviewer, approval, pipeline run, deployment timestamp. Full traceability.

Auditor: "What is the recovery time objective for this service?"

You point to the annotation: nis2/recovery-time-objective: 4h. You click through to the TechDocs recovery procedure, which documents the restore process and shows it was last tested six weeks ago.

Total time for this exchange: ten minutes. Without a catalogue, the same questions take an hour or more, involve multiple people, and produce answers the auditor trusts less.

Start with the catalogue

If you are preparing for a NIS2 audit and considering Backstage, here is our recommendation: start with the catalogue and TechDocs. Do not try to deploy every plugin and integration on day one.

Week 1-2: Deploy Backstage with authentication. Define your catalog-info.yaml schema with NIS2 annotations. Write the CI check that validates required fields. Start populating — begin with your ten most critical production services.

Week 3-4: Add TechDocs templates for risk assessment and recovery procedures. Get the first three teams to fill them in. Iterate on the templates based on their feedback.

Month 2: Model external dependencies as Resource entities. This is your supply chain register. Add the identity provider integration.

Month 3: Add security plugins. Connect vulnerability scanning data. Run a mock audit internally — have someone play the auditor and go through the questions listed above. Find the gaps.

This is not fast. It should not be fast. A catalogue that is rushed into existence and populated with garbage data is worse than no catalogue at all. The value comes from accuracy and currency, not from speed of deployment.

Backstage is not the answer to NIS2 compliance. But it is the connective tissue that makes the rest of your compliance tooling auditable, discoverable, and fast to query. When the auditor is sitting across from your platform team, that speed and confidence is what separates a clean audit from a finding.

---

This article is published on Clouds of Europe, a practitioner community building European cloud independence. We assess infrastructure tooling based on real production experience — no vendor sponsorship, no product agenda.