NIS2 and DORA architecture evidence: what security teams actually need

The short answer

For NIS2 and DORA, architecture evidence becomes useful when it is current, timestamped, scoped, and explainable. A PDF exported from an old diagramming tool is better than nothing, but it is rarely enough when an auditor or security lead wants proof that the documented system matches what actually ran.

What auditors and security teams are really asking

The visible question is often "Can you show us the architecture?"

The real questions underneath are usually:

• what was live at the time of the review or incident
• who approved the documented architecture
• what changed after approval
• which changes carried security or operational impact
• whether the documentation process is repeatable, not one-off

That is why architecture evidence should be treated like an operating record, not a presentation asset.

The minimum evidence package

If a team wants architecture evidence that holds up under pressure, the minimum package should include:

1. a timestamped architecture snapshot
2. the scope of that snapshot, such as organisation, project, or subscription
3. a repeatable collection method
4. a drift or delta view when changes occurred
5. an export or audit trail that can be stored and referenced later

Without that structure, teams end up arguing over which screenshot is the right one.

What good architecture evidence looks like

Evidence element	Why it matters	What weak evidence looks like
Timestamped snapshot	Proves when the architecture was observed	A diagram with no capture date
Clear scope	Tells reviewers what environment was included	"Production" with no subscription or project boundary
Drift history	Shows whether architecture changed after approval	No explanation for added or removed resources
Exportable record	Makes audit storage and review easier	A browser tab nobody saved
Human-readable explanation	Helps leadership understand risk quickly	Raw resource inventory with no interpretation

Why drift matters more than most teams expect

A current diagram is useful. A current diagram plus drift history is much more valuable.

That is because regulated reviews often happen after a change, an outage, or a security concern. At that point, reviewers do not only need the current state. They need to understand:

• what changed
• when it changed
• whether the change was expected
• whether the change increased risk

This is where architecture evidence becomes operational instead of decorative.

A better operating model for compliance teams

The strongest pattern is not "draw once, export once." It is:

1. capture a live architecture baseline
2. re-scan on a defined cadence or after meaningful change
3. compare current state to the last approved state
4. keep exports tied to the actual scan timestamp
5. use the same evidence set for engineering, audit, and leadership reviews

That model reduces duplication because one trustworthy evidence flow serves multiple stakeholders.

Common failure modes

Most compliance evidence fails in one of four ways:

• the diagram is accurate only on the day it was drawn
• the infrastructure scope is too vague
• exports exist, but nobody knows which one maps to the incident window
• architecture and operational data live in separate tools with no bridge between them

These are process failures more than tooling failures, but the wrong tooling makes them worse.

What to ask before you trust an evidence workflow

Before a security or compliance team signs off on architecture evidence, ask:

• can we recreate the same snapshot method next week
• can we explain the permissions used to collect the data
• can we show what changed between two snapshots
• can a non-engineer understand why a change matters
• can we export and retain the result for later review

If the answer is "not yet," the workflow is probably still presentation-grade instead of audit-grade.

Bottom line

Security teams do not need more static diagrams. They need architecture evidence that behaves like an operational record: live, timestamped, scoped, and traceable across change. That is the standard worth building toward for both NIS2 and DORA.