IT-Grundschutz evidence collected from your own network
AssetObserve provides an initial technical evidence mapping for selected BSI IT-Grundschutz building blocks. It supports preparation and gap review; it is not a BSI audit and not a certification result.
IT-Grundschutz is documentation-heavy by design, and the technical building blocks are the part where a current, honest inventory saves the most time. AssetObserve collects that evidence read-only and shows, per building block, what the scan established and what still needs a documented statement.
Building blocks with technical evidence
The IT-Grundschutz modules AssetObserve currently maps.
| ORP.4 - identity and access management | Identity lifecycle, role separation, privileged access and multi-factor signals: local administrator sprawl, domain administrator counts, stale administrator and user accounts, and password-policy minimums. Declaration required alongside the technical evidence. |
|---|---|
| ISMS.1 and ORP.2 - security management and personnel | Management policy, risk treatment, management review, joiner/leaver safeguards and awareness training are handled as named declarations backed by reviewed document evidence, not invented from a network scan. |
| CON.1 and CON.3 - cryptography and backup | Disk encryption, TLS hygiene, backup coverage, backup failures and recovery signals are combined with reviewed cryptography, backup, restore-test and offline-copy evidence. |
| OPS.1.1.1 to OPS.1.1.5 - secure IT operation | Asset inventory, proper administration, patch and change management, malware protection and logging use collector signals alongside reviewed operating procedures and accountable control ownership. |
| DER.1, DER.2.1 and BCM.1 - detection, incident handling and continuity | Logging signals support detection; incident roles, exercises, recovery objectives and continuity plans remain explicitly declared and document-reviewed before a management attestation is available. |
How the evidence is collected
Read-only, scope-bound, credentials stay on your side.
A customer-side agent runs inside your network and performs authorized discovery: network sweeps, WinRM for Windows, SSH for Linux and macOS, read-only LDAPS for Active Directory, SNMP for network devices and printers, and cloud APIs for Azure, Microsoft 365, AWS, Google Cloud, OCI and Open Telekom Cloud. Scan credentials stay in a vault under your control and are never written to the workspace database.
Where a protocol carries genuine operational risk, AssetObserve deliberately does not probe. Modbus device identification uses only the standard read-only identification request; DLMS/COSEM metering access is left to a certified smart-meter gateway under BSI TR-03109 rather than a generic scanner.
Alongside the other frameworks
The same evidence feeds more than one view.
The IT-Grundschutz view sits next to NIS2 Article 21(2), ISO/IEC 27001, GDPR Article 32, DORA supplier risk, TISAX, cyber-insurance evidence packs and Green IT. One collection run feeds every view, so a host that is missing a patch shows up once as a finding and then wherever each framework needs it.
Where the claim stops
- This is an initial technical evidence mapping for selected building blocks, not full IT-Grundschutz coverage and not a BSI audit or certification result.
- Organisational building blocks that rest on documented process cannot be scanned. They appear as declaration-backed or declaration-only controls.
- Discovery is read-only and scope-bound: no exploitation, no credential guessing, no detection evasion and no changes to a scanned host.
Common questions
01/ Does AssetObserve cover all of BSI IT-Grundschutz?
No. It maps a selected core: ISMS.1, ORP.2, ORP.4, CON.1, CON.3, OPS.1.1.1 to OPS.1.1.5, DER.1, DER.2.1 and BCM.1. It supports preparation, evidence review and management attestation readiness; it is not a BSI audit or certification result.
02/ Can a scan prove a DER.1 detection requirement on its own?
No. AssetObserve collects supporting logging and audit-policy signals, then requires the declared detection process, linked document evidence and a current evidence review. Incident roles and exercises belong to DER.2.1 and are never inferred from network collection.
03/ Is IT-Grundschutz evidence separate from the NIS2 report?
They are separate views over the same evidence. One authorized collection run feeds the IT-Grundschutz view, the NIS2 Article 21(2) view, ISO/IEC 27001, GDPR and the other frameworks, so findings are not re-collected per framework.
04/ Does the scanner touch OT or metering devices?
Only within a deliberately narrow boundary. Modbus devices get the standard read-only device-identification request and nothing else. DLMS/COSEM smart-meter access is not implemented, because that path is architecturally meant to go through a certified smart-meter gateway under BSI TR-03109.