Compliance mapping

Which NIS2 Article 21(2) measures and ISO/IEC 27001:2022 Annex A controls Straza supplies evidence for, and the mechanism behind each one.

On this page

A compliance officer or an auditor reads this page to see which NIS2 Article 21(2) measures and ISO/IEC 27001:2022 Annex A controls Straza can supply evidence for, and which mechanism backs each row. It describes evidence the product can supply, and it makes no compliance determination for your organization. NIS2 duties, an ISO/IEC 27001 management system and AI Act obligations depend on the organization, the system and its use, so use the mappings below as input to that assessment.

Known limits lists what these mechanisms leave with you, so read it beside this page.

NIS2, article 21(2)

For (a), a PolicySet is a YAML document you keep in version control. Activation compiles every active set into one snapshot whose id is a hash of its content and whose signature the client verifies before enforcing it.

For (b), a SCIM deactivation, an admin disable and a lock all run the same cascade. It writes a revocation record, revokes every active session, denylists the identity on every replica, pushes to the enrolled machines and writes one identity event on the chain. A SCIM deactivation also removes the user’s own OAuth grants and pasted tokens, with one audit record per grant. Every login success or refusal is a chained authentication event, and so is every session that its person signs out, an admin revokes, or the idle or lifetime sweeper closes. The sessions a kill revokes are counted on the kill’s identity event. The source address and user agent ride on an authentication event when a client connection produced it, so a session the idle sweeper ends carries neither.

Under (c), tokens are verified locally from cached keys. A client keeps deciding from its verified snapshot for at most the configured grace period, which is zero in the enterprise profile, before it denies everything.

Row (d) rests on the gateway. It builds each role’s catalog on the server, runs a tool container read-only with all capabilities dropped and no network unless the manifest asks, and passes the injected credential by environment variable name so it never appears in an argument list.

Under (e), the enterprise profile denies a local tool that no rule allows, and an interpreter invocation is tagged for policy to deny or classify. With the enterprise default, a coding harness gets a session token only from a check-in whose reported hashes match the registry. The hook on a machine where the agent can run anything is advisory and not a security boundary, and an MCP server that a user adds to a harness outside the gateway is that user’s responsibility. The part of this row that holds against a hostile agent is therefore the gateway, and Known limits lists both exclusions.

Row (g) rests on knowledge packs. A pack is bound to a role that carries tools, never to a Straza role or an approver role, and the check-in response hands every matching pack to the session. A change to a pack writes no audit record today, as Known limits records.

For (h), a session signing key rotation runs in two phases. The new key is staged and every replica holds it before any replica signs with it, and the previous key keeps verifying as retiring until every credential it signed has expired.

Under (i), an assignment carries valid_from and valid_to, and an expired one stops counting at the next role resolution.

Row (j) has two gaps to know about. The standalone profile authenticates with passwords hashed with bcrypt, and passkeys for that built-in issuer are on the roadmap rather than shipped, a gap that Known limits also lists. In both profiles the break-glass account signs in with a password at the server’s own emergency page, outside your identity provider’s MFA, and every use of it is alarmed on the audit chain. The gateway enforces the attestation minimum from the token on every call.

ISO/IEC 27001:2022 Annex A

Annex A of ISO/IEC 27001:2022 lists the controls an organization selects for its management system. These are the ones Straza produces evidence for.

For A.5.17, an admin API token is hashed before it is stored, the identity manager’s SCIM credential included. The first boot prints the bootstrap administrator’s password once, as a warning line in the server log, so every copy of that log holds it until it changes. Known limits lists that log and the plain-text manifest values, each with what reduces it.

Under A.8.2 to A.8.5, admin.roleAreas maps a role to scopes of the form area:read or area:write over the areas that Delegated admin lists. Among them is drafts, whose drafts:read and drafts:write open config drafts. Admin API tokens carry the same scopes, so an auditor reads the chain without touching identity or policy. Delegation by object sits beside that map. Every MCP server names one role when it is registered, and a holder of that role administers that server and no other, so the people who run an MCP server own it without an admin role over the whole install. Both paths write the same records.

For A.8.15, every admin mutation on the chain names who acted and through which credential, whether a login, a session or a named admin API token.

For A.8.9, a managed install reports hashes of its binary, its configuration and its hook wiring, and a reported hash that no registered row allows reads as tampering. The server registers the hook wiring hashes itself, and the binary and configuration count once an admin registers theirs. The hashes come from the client, so the managed level shows that the reported files match and does not prove which program reported them, as Known limits records.

Under A.8.16, the enterprise profile blocks a request rather than drop its audit event when the in-memory queue is full, so load alone does not drop a record. Known limits lists the loss of audit records as a limit, and the security model names each case in which a record can still be lost. A.8.28 rests on the counting store in the test suite, which fails the build when a request path gains a database read.

For A.5.3, the drafts publish route refuses an admin API token and an AI agent whatever they hold, so a draft a pipeline writes waits for a person. An admin API token keeps its direct writes, each a one-item draft the token publishes in the same request. A token that holds apps, identity or policy at write therefore still changes objects without waiting. Who may draft and publish shows who may write a draft and who may publish one.

With admin.secondPerson: true in straza.yaml, a draft whose check lists a risk cannot be published by anyone who wrote it, minted the token that wrote it, or sponsors the agent that wrote it. A change that widens access and a server removal both raise such a risk. While the setting is on, a direct admin write whose check lists a risk is refused to every caller until it goes through a draft.

The setting leaves assignments immediate, so a role nobody holds can be given ungated access and then assigned, and your identity manager’s approval of assignments closes that path. Nor does the setting cover a credential of the person that an agent can read on that person’s machine, the strazactl login and an unexpired ID token alike, which publishes as that person. Known limits lists that reach of an agent with what reduces it.

A server’s pause, its secrets and every assignment stay immediate operations, so an incident response never waits. Under A.8.32, the draft is the change request and its publish the change record. draft.publish names the publisher, the proposer, the resulting snapshot and the risks acknowledged, every record the publish writes carries the draft’s number, and strazactl drafts revert undoes a publish through a new draft. A file in the apps directory proposes a draft that a person publishes, and deleting the file proposes the server’s removal the same way, so the directory never changes a live server by itself. Propose and publish a change walks a draft from start to publish.

The EU AI Act

There is no AI Act product certification. Conformity for a high-risk system is mostly the provider’s own assessment, and a vendor who says a product makes you compliant is overclaiming. Straza is a deterministic system of rule matching, token cryptography and hash chains. No shipped binary performs model inference, the classify mode is a heuristic, and the audit sentinel is rule-based detection, so the Act’s duties fall on your agents and their models and not on this software. This page does not claim compliance on your behalf.

What Straza gives an operator whose agents do fall under the Act is the substrate its duties ask for. Every session is bound to a person or a governed AI agent, so the record of on whose behalf an agent acted exists. The hash chain logs every governed call with its command, arguments, decision and policy snapshot. An approval gate puts a named person’s approval in front of a specific action, the kill switch stops an agent from the identity system, and a sink keeps the record for as long as you decide.

An approval gate is an oversight control, and neither this page nor the product describes it as making an agent’s output human. The approval is as human as the approver’s credentials. An admin login can enroll a new approval device for its own user, so an AI agent that can use its person’s admin login can enroll a device of its own and decide the requests that person may decide, as Known limits records. Everything provider-side, risk management, technical documentation, conformity assessment and registration, is yours, and Straza supplies evidence into those processes without constituting them.