Regulatory Evidence
Evidence support for control workflows
Attesto provides evidence support for compliance controls. It does not certify legal compliance by itself. Customers remain responsible for legal interpretation, control design, source-system quality, and organizational procedures.
Control mapping methodology
Attesto maps evidence packs to compliance-support areas, not legal conclusions. Every mapping must describe what the evidence proves, what it does not prove, and what the customer must still do.
| Evidence pack | What it supports | Limitation |
|---|---|---|
| Lifecycle readiness | Event -> receipt -> window -> checkpoint -> witness -> anchor -> bundle -> offline verify. | Does not prove source decision correctness. |
| Fork defense | Conflicting history detection and verifier rejection of ambiguity. | Requires witness visibility over the affected stream. |
| Connector assurance | Real connector auth, replay handling, source reference, and revoke behavior. | Does not certify the external provider account or source process. |
| Local Vault assurance | Outbound relay, encrypted spool, source attestation, optional customer witness. | Customer must operate and secure the edge environment. |
EU AI Act support
Attesto evidence streams can support logging, traceability, technical documentation, post-market monitoring, and incident evidence for AI systems. Customers must decide which events are required for their AI system category and legal obligations.
EU AI Act Article 12 logging
Article 12 requires high-risk AI systems to technically allow automatic event logging over the system lifetime, with traceability for risk situations, post-market monitoring, and operation monitoring. Attesto supports that workflow by producing ordered events, signed receipts, stream heads, verifier bundles, and deterministic Article 12 evidence reports.
The phrase "Voldoe aan Artikel 13 met 1 regel code" is product shorthand for adding one Attesto integration line that starts verifier-ready evidence capture for transparency work. The deterministic CLI report remains attesto report article12 because it maps the technical logging trail to Article 12-style logging evidence. It is not a legal conclusion. Customers still decide whether their system is high-risk, which events are relevant, how long logs must be retained, who reviews them, how transparency materials are written, and how the organization responds to incidents.
The concrete one-line Gateway integration is:
export OPENAI_BASE_URL=http://localhost:8765/v1
In production, replace localhost with the deployed
Attesto Gateway host and keep provider keys plus Attesto system keys
in server-side secret storage.
| Article 12 theme | Attesto evidence support | Customer responsibility |
|---|---|---|
| Automatic logs over lifetime | SDK, gateway, MCP, connector, and Local Vault events with receipts and source timestamps. | Choose the right source events and retention period. |
| Traceability for risk situations | Incident, override, policy, decision, and failure events linked by stream sequence. | Define risk scenarios and escalation workflows. |
| Post-market monitoring | Verifier bundles, truth packages, anchors, and Article 12 reports. | Review reports and act on findings. |
| Operation monitoring | Latency, status, actor/source references, payload commitments, and completeness checks. | Ensure source-system facts are accurate and proportionate. |
Official source: Regulation (EU) 2024/1689, Article 12.
EU AI Act Article 13 transparency support
Article 13 concerns transparency and information that enables deployers to understand a high-risk AI system's capabilities, limitations, operation, and oversight context. Attesto does not generate legal instructions for use by itself. It gives teams verifiable evidence they can cite in those materials: what was logged, which model/policy path was used, which source timestamp was preserved, what changed over time, and which receipts or bundles a third party can verify.
The adoption phrase "Meet Article 13 with 1 line of code" is a practical implementation shortcut, not a legal conclusion. The one line starts evidence capture; the customer still owns the content, suitability, completeness, language, and legal review of Article 13 materials.
| Article 13 support area | Attesto evidence support | Customer responsibility |
|---|---|---|
| System behavior explanation | Model decision events, policy references, source timestamps, payload commitments, and receipt IDs. | Write accurate user-facing explanations and instructions. |
| Operational transparency | Verifier bundles, truth packages, status/reliability evidence, and audit portal reports. | Decide which evidence belongs in customer-facing or regulator-facing material. |
| Change history | Proofstream sequence, windows, checkpoints, witness statements, anchors, and Proof of Evolution evidence where enabled. | Explain relevant changes, limitations, and human oversight measures. |
NIS2 support
Attesto can support cybersecurity risk management evidence, supply-chain assurance, auditability, and incident evidence by recording ordered events and connector observations. Customers remain responsible for the actual security controls and governance.
Cyber Resilience Act support
Attesto can support product security evidence, vulnerability handling evidence, secure update evidence, and support-process traceability. It does not decide whether a product satisfies every CRA obligation.
ISO/IEC 27001 alignment
Attesto is building ISO/IEC 27001 audit-readiness into its operating model from the start. The alignment pack maps release evidence to ISMS governance, risk assessment, asset inventory, access control, cryptography, logging, supplier assurance, secure development, vulnerability management, incident management, backup and restore, business continuity, and continual improvement themes.
This is preparation evidence only. It does not state that Attesto has passed an accredited certification audit. Management still owns the ISMS scope, risk register, policies, internal audit, corrective actions, supplier review, and certification engagement.
Reference: ISO/IEC 27001:2022 information security management systems.
Attesto's public explanation of this operating model is documented in Security Management. It covers ISMS scope, risk register, asset register, supplier register, incident register, internal audit plan, management review, and evidence boundaries.
The broader Certification Readiness guide explains Attesto's preparation path for ISO/IEC 27001, SOC 2 Type II, ISO/IEC 27701, Cyber Essentials Plus, NEN 7510, ENSIA/BIO, and eIDAS 2.0 alignment. It is preparation evidence only and does not state certification or legal-compliance outcomes.
ISO 27001, SOC 2, and eIDAS/evidence support
- ISO 27001: ISMS preparation evidence, logging, access-control evidence, supplier assurance, incident management, integrity evidence.
- SOC 2 Type II: period-based evidence support for security, availability, processing integrity, confidentiality, and privacy where scoped.
- ISO 27701: later privacy-management evidence support for PII roles, data-flow inventory, and privacy-risk processes.
- Cyber Essentials Plus: later UK baseline security preparation when procurement requires it.
- NEN 7510: later Dutch healthcare security preparation if healthcare becomes active market scope.
- ENSIA/BIO: Dutch public-sector evidence support without certification language.
- eIDAS 2.0/evidence: timestamps, electronic ledgers, integrity, non-repudiation support, and verifier-first evidence alignment without qualified trust-service claims.
For all of these areas, Attesto evidence supports an audit trail. It does not replace legal counsel, auditor judgment, or customer control ownership.
