Practical guide 05 / 05
Cybersecurity for government has to work when it matters: a compromised account, a problematic update or the loss of a critical service. A documented policy is necessary, but tested technical and organisational controls make that policy operational.
Build three capabilities together
Limit access, control software delivery and practise restoration. NIST describes Zero Trust as an approach focused on resources rather than implicit trust derived from network location. [1] That does not mean replacing every system immediately. One important public service is a sensible first assessment boundary.
The questions behind the security budget
Can one account reach more than its task requires? Can the team identify the software actually running in production? Has anyone demonstrated that backups can restore a usable service under realistic conditions? These questions connect architecture to the organisation’s ability to keep working.
Digital sovereignty in this context means retaining control over access, change and recovery. It is more useful to demonstrate these capabilities for a defined service than to describe an ambitious target architecture whose operating assumptions remain untested.
Where government security controls become disconnected
Network admission substitutes for authorisation
A VPN can protect a connection, but it does not determine which records a person or service should access. Permanent administrative rights and shared accounts make restrictions and accountability harder. Inspect users, devices and machine identities along actual data flows rather than relying only on network boundaries.
The evidence chain breaks before production
A repository scan does not prove that the reviewed version is the one deployed. Dependencies, build environments, artefacts and release processes can diverge. A software bill of materials improves component visibility; it does not independently prove absence of vulnerabilities. A signature establishes provenance and integrity, not automatic harmlessness.
Backup succeeds but restoration is unknown
A successful backup job does not demonstrate that data, keys, identities and interfaces can work together after an incident. Recovery may depend on a service that is unavailable in the same scenario. Test the complete application and its business functions, not just whether files can be copied back.
Prioritise a service with meaningful impact. A complete, bounded assessment of one critical workflow provides more useful evidence than a partial inventory of every security tool in the organisation.
The solution: connect three protective layers
1. Make privileges bounded and accountable
Associate roles and service accounts with specific tasks. Remove unnecessary access, limit administrative elevation and review access to sensitive resources separately. Introduce segmentation around known required connections. Untested restrictions can disrupt service availability, so deployment needs staging and rollback.
2. Make software delivery traceable
Connect source version, dependencies, security checks, build artefact and release approval. NIST SSDF organises secure-development practices across the software lifecycle. [2] For a particular service, implementation may include signed artefacts, controlled registries, component inventories and admission checks before deployment. A familiar filename must not be enough to admit an unapproved release.
3. Plan detection and restoration together
Define which events trigger alerts and who acts on them. Protect recovery information and required keys with appropriate separation. Exercise restoration, including business validation. Restoring a potentially compromised state requires additional assurance; returning online quickly is not the only objective.
Responsibilities belong in the architecture. NIST’s Zero Trust planning guide highlights cooperation among organisational stakeholders. [3] A product cannot replace risk ownership or the decision process required during a security incident.
A practical assessment and improvement sequence
1. Map the service and its dependencies
Record the business purpose, operator, important data, identities, interfaces and software suppliers. Agree tolerated interruption and data loss with the service owner. The objectives must reflect the service; generic figures from a product brochure are not an adequate basis.
2. Test controls against concrete scenarios
Within an authorised test scope, verify that an unauthorised user cannot access protected data, expired service credentials lose access, an unapproved release is stopped and an alert reaches an accountable responder. Keep evidence reproducible, scoped and attributable to a specific version and time.
3. Perform a real restoration
Use a protected test environment. Restore the application and data, then check integrity, permissions and essential business functions. Measure the actual elapsed time. Record missing information, unavailable dependencies and skill gaps. A tabletop exercise can complement this process, but does not replace execution.
4. Close the control loop
A relevant finding becomes a ticket with risk, owner and due date. After remediation, rerun the test. Close the finding based on evidence, not merely a configuration change. Automation can collect observations, route work and refresh evidence while risk-sensitive changes retain explicit approvals.
Deliverables should include a dependency model, access matrix, prioritised improvements, release evidence, recovery test results and residual risks. Every unresolved item needs an accountable owner, not only a dashboard status.
Procure demonstrated effectiveness rather than broad promises
Ask about the scope of an assessment and the responsibilities retained by the customer. For external cloud services, the BSI explicitly states that a C5 attestation alone is not sufficient to satisfy every requirement of its minimum standard. [4] Apply the same reasoning to security procurement: which service, control and period are actually covered by the evidence?
Use measures that reflect operating capability
Examples include the proportion of administrative accounts reviewed, time to remediate relevant findings and successful restoration of critical services within the agreed test scope. An initial rise in detected vulnerabilities can indicate improved visibility. The raw number of findings is therefore not a reliable standalone success metric.
An illustrative acceptance scenario: one service has an agreed recovery-time objective of eight hours and tolerated data loss of four hours. A test takes eleven hours. The recovery-time objective is not met, even if the service eventually becomes available. The gap creates a specific improvement task. These numbers are examples, not general recommendations.
Assess a critical service with Insight42
Review protective controls and recovery capability together. Insight42’s published services cover cloud security, encryption and technical platform delivery. [5] A bounded engagement can connect controls, evidence and operational dependencies into a prioritised implementation plan. It is not an automatic certification or regulatory approval.
Contact: support@insight42.com. Describe the service, protection needs and operating concerns at a general level. Credentials, vulnerability details and sensitive architecture plans should move only through an agreed secure exchange.
Frequently asked questions about government cybersecurity
Does Zero Trust replace IT-Grundschutz?
No. Zero Trust is an architectural approach, not a substitute for information security management or all organisational requirements. Existing German IT-Grundschutz work should connect to actual access controls and operational evidence.
Is a software bill of materials sufficient?
No. An SBOM improves component transparency. It needs a process for assessing, fixing and retesting relevant risks. Without a connection to the deployed version, even a complete inventory can fail to describe the real service.
Do we need to replace all existing tools?
No. Start with one service and its most important risks. Existing tools can remain where they support the required controls and evidence. Consolidation may be useful, but buying a new platform should not be the automatic first step.
Does this apply to German defence projects?
The engineering principles can inform a discussion, but this article does not establish suitability for classified information or any particular Bundeswehr environment. Project-specific protection requirements, special conditions and required approvals must be assessed separately.
The takeaway: A secure public service is not only documented. Its access boundaries, software provenance and recovery capability can be tested within a defined scope.
Sources and technical references
[1] NIST: SP 800-207, Zero Trust Architecture
[2] NIST: SP 800-218, Secure Software Development Framework 1.1
[3] NIST: CSWP 20, Planning for a Zero Trust Architecture
[4] BSI: FAQ zum Mindeststandard Externe Cloud-Dienste
Sources checked: 27 September 2026. Calculations and diagrams are illustrative.