ISO/IEC 27001:2022, Annex A
What ISO 27001 requires in terms of logging and evidence, and what Logsiegel contributes
If you run an ISMS to ISO 27001, you have to show the auditor that logs not only exist but are protected against falsification. For AI systems inside the scope, that holds just as much as for any server. Logsiegel supplies that protection in a form the auditor can recompute personally.
Who this applies to
Organizations with an ISMS to ISO/IEC 27001, certified or preparing for certification, and their suppliers, who have to supply evidence within supplier management (A.5.19 to A.5.22). An AI system that makes decisions inside the scope is an asset like any other.
What the regulation requires in terms of records
The relevant controls from Annex A (2022 edition):
| Reference | Requirement |
|---|---|
| A.8.15 | Logging: logs of activities, exceptions, faults and other relevant events are to be produced, stored, protected and analyzed. The implementation guidance (ISO/IEC 27002) calls for protection against tampering and unauthorized access. |
| A.8.16 | Monitoring activities: networks, systems and applications are to be monitored for anomalous behavior; reliable records are the basis for that. |
| A.5.28 | Collection of evidence: procedures for the identification, collection, acquisition and preservation of evidence related to information security events, so that it remains usable in disciplinary and legal proceedings. |
| A.5.33 | Protection of records: records are to be protected from loss, destruction, falsification and unauthorized access, throughout the whole retention period. |
| A.8.17 | Clock synchronization: the clocks of systems are to be synchronized to an approved time source, so that records can be correlated in time. |
| A.5.19 to A.5.22 | Supplier relationships: define security requirements for suppliers and monitor that they are met. An AI provider has to be able to supply evidence. |
What Logsiegel contributes today
- Unaltered records, verifiable. Every entry is hash-linked to the one before it; at intervals a Merkle root is formed and signed with Ed25519 (a checkpoint). Any later edit, reorder or truncation makes
logsiegel verifyfail. Exactly the protection against tampering A.8.15 and A.5.33 call for, with the difference that the auditor does not have to believe it but checks it withlogsiegel verify. - Evidence under A.5.28.
logsiegel receiptbuilds a file for one single action, made of the entry, an inclusion proof and a signed checkpoint. An auditor, customer or court verifies it offline against your published key, without access to your systems and without seeing the rest of the trail. The receipt is built so that an expert can verify it without access to your system. - Retention you can prove. A signed checkpoint shows that at a given moment the trail had a certain length and a certain content. Anyone who truncates it later stands out against every checkpoint or receipt handed out earlier. That makes A.5.33 provable across the retention period, not merely asserted.
- Evidence for suppliers. As an AI provider you hand the client signed checkpoints; the client checks consistency without seeing content. Concrete evidence for A.5.20 to A.5.22.
- A readable dossier.
logsiegel exportwrites the trail as a Markdown dossier for people who do not want to touch a command line. As an audit annex. - Metadata only in the trail. What enters the chain is event metadata and salted hashes; inputs and outputs are kept separately, encrypted per entry. The content of an entry can be deleted by deleting its key (crypto-shredding), without breaking the chain.
What is in progress planned
- Qualified timestamps and an independent witness: then the time in the trail is no longer just the operator's synchronized clock (A.8.17) but confirmed from outside.
- Integration with the OpenTelemetry Collector, so that checkpoints become visible in existing monitoring (A.8.16).
What Logsiegel does not do
- The ISMS itself. Risk assessment, Statement of Applicability, management review, internal audits: separate work, separate tools.
- Analysis and monitoring. A.8.15 also asks for analysis, A.8.16 for monitoring. Logsiegel supplies unaltered facts for that, not the analysis.
- The time source. Clock synchronization (A.8.17) remains your job; Logsiegel takes the system time.
- Completeness. What is proven is that the recorded material is unaltered, never that everything was recorded. That is an integration question: the adapter has to sit at a point every action must pass (LiteLLM today, MCP proxy in progress).
- Protection against the operator itself. Whoever holds the signing key could rewrite the trail and sign it again. That comes to light precisely when somebody else holds an earlier checkpoint or receipt. So hand your checkpoints out; counter-signing by an independent witness is the next stage of the project.
- Legal assessment. Whether your system falls under the regulation, which duties apply in detail and whether a receipt is enough in a given case is decided by your legal or compliance review, not by this tool.
How to put it to work
1. Install it and create a trail
The SDK is Python, Apache 2.0, no server and no account. The origin (origin) names the system whose actions are being recorded.
pip install logsiegel
logsiegel init ./trail --origin "acme.example/support-agent"2. Plug the adapter in at the point every action must pass
If your AI traffic runs through LiteLLM, every completion becomes a signable inference entry, and errors are recorded as an anomaly. Human interventions you record explicitly, as an event of their own.
import litellm
from logsiegel.integrations.litellm_logger import LogsiegelLogger
litellm.callbacks = [LogsiegelLogger("/var/lib/logsiegel/prod", store_payload=True)]3. Create checkpoints and hand them out
Create checkpoints regularly (via cron, for instance) and put them outside your own infrastructure: with the auditor, with the customer, in someone else's repository. Only a checkpoint you no longer control alone makes the trail hold up against yourself.
logsiegel checkpoint ./trail
logsiegel verify ./trail4. File checkpoints as audit evidence
Put signed checkpoints into the document control system of the ISMS and point to the procedure in the Statement of Applicability under A.8.15 and A.5.33. The auditor spot-checks with logsiegel verify against the filed checkpoint.
5. Hand out the receipt when someone asks
Instead of database extracts you hand out a single receipt. The other side verifies it in the browser at logsiegel.com/verifier or on the command line, both offline.
logsiegel receipt ./trail --seq 1284 --out receipt.json
logsiegel verify-receipt receipt.json --pubkey logsiegel.pubMore regulations: EU AI Act GDPR DORA NIS2 / critical infrastructure ISO/IEC 42001 GoBD eIDAS Overview
Legal status September 2026. This page is a technical assessment by the project, not legal advice and not a conformity statement. Please check the references against the current text of the law. Corrections welcome via GitHub issue.