Zero trust belongs to that set of terms that appear more often in tenders and board packs than in audit reports. There is a substantive reason for that: zero trust describes a design decision, not a requirement. No legal act and no management system standard calls for zero trust by name. For compliance purposes, what counts is therefore not the label but whether the controls that follow from the principle demonstrably work.
A reference description does exist, though. NIST SP 800-207, "Zero Trust Architecture" (August 2020), is the most frequently cited elaboration of the model and describes it as a planning approach for infrastructure and workflows. It is a publication with recommendation status, not a testing scheme: there is no certificate and no declaration of conformity attached to it, and citing it in a concept paper answers none of the questions asked further down in an audit.
What the principle says
Classical network architectures distinguish inside from outside. Once past the perimeter, you move around largely freely. Zero trust replaces that one-off border check with a continuous decision at every point of access. Three assumptions carry the model:
- Location in the network establishes no trust. A device is not trustworthy because it happens to sit in an office.
- Every request is authenticated and authorised, not just the first one in a session.
- The decision takes in the state of the device, the context of the access and the sensitivity of the resource, alongside the identity.
What follows from this is not a set of new controls but a different arrangement of familiar ones: strong authentication, fine-grained authorisation, device posture checks, segmentation down to the level of individual applications, and logging that makes access decisions traceable.
What zero trust does not mean
Three misunderstandings come up regularly, and all three are exposed in an audit.
Zero trust does not replace segmentation. The principle moves the control closer to the resource; it does not abolish it. Network separation remains the measure that limits how far an attack can spread.
Zero trust cannot be procured. There are building blocks that support the principle, but no product whose installation produces the state. Anyone presenting a purchase as implementation of the principle has to explain in the audit which access decision actually changed as a result.
Zero trust cannot be certified. What gets certified is a management system, not an architecture. An ISO/IEC 27001 certificate says nothing about whether an organisation works on zero trust principles, and the reverse holds too.
Regulatory context
The applicable requirements are framed as outcomes, not architectures. § 30(2) sentence 2 of the German BSI Act is not a catalogue of suggestions but a binding minimum: the measures must at least cover the ten points listed there. Two of them are relevant here:
- No. 9: drawing up concepts for personnel security, access control and the administration of ICT systems, products and processes.
- No. 10: the use of solutions for multi-factor authentication or continuous authentication, secured voice, video and text communication, and, where applicable, secured emergency communication systems within the entity.
The half-sentence on continuous authentication is the point where an element typical of zero trust surfaces directly in the statute. It stands there, however, as a statutory alternative to multi-factor authentication, not as an architectural requirement: an entity using multi-factor authentication satisfies no. 10 on that point without authenticating continuously.
Art. 32(1) GDPR requires technical and organisational measures appropriate to the risk, assessed against the state of the art, the costs of implementation, and the nature, scope, context and purposes of the processing. That too is open as to means. A zero trust architecture can support appropriateness, but it does not evidence it by itself.
For ISO/IEC 27001 the same holds in a different form: what governs is that the chosen controls follow from the risk treatment and are justified in the Statement of Applicability. An architectural decision does not replace that justification.
What auditors ask
Auditors are rarely interested in the model and almost always in its consequences. Four questions are typical. Which resources are protected such that access from the internal network is not sufficient? How is the state of an accessing device determined, and what happens when it does not meet the requirements? Which systems are exempt, and who approved the exemption? And finally: can it be shown after the fact, for a specific access, which criteria led to it being allowed?
That last question tends to decide the finding. An architecture whose decisions are not logged cannot be examined in an audit.
What holds up in an audit
What holds up are records that keep design, implementation and effectiveness apart: a documented access architecture with the protection needs named, the rule sets behind the access decision in their current version, a maintained list of exemptions with expiry dates and approvals, logs of denied and granted access for a sampling period, and an examination report independently confirming effectiveness, whether from an internal audit or from a penetration test that deliberately probed lateral movement inside the network.
Getting started without a mega-project
The common mistake is insisting on completeness. A stepwise approach is more durable: start with the applications whose protection needs are highest, tighten authentication and authorisation there, measure the results, and only then widen the approach. Each step yields evidence in its own right. A multi-year programme with no interim results yields none until it finishes.
Zero trust in Rizzqo
Zero trust is a design decision, and design decisions cannot be ticked off. Rizzqo carries the outcomes an assessor actually asks for, and those sit as ISO/IEC 27002 requirements on the objects whose category they concern: access control, strong authentication, secured communication, logging.
That separation is more useful than it first seems. It keeps open the question of whether a particular architectural decision achieves the required effect, instead of answering it with the architecture's name. And it supplies the yardstick, because an object inherits the protection needs of the primary assets it carries: how strictly each request must be checked follows from what actually hangs on it, not from a model's maturity level.