Vai al contenuto principale
Stai mettendo lo scope del tuo ISMS attorno a un agent AI e il tuo auditor vuole sapere quali controlli dell’Annex A puoi effettivamente evidenziare sul percorso della richiesta. Su un gateway hosted la risposta onesta è ristretta e verificabile: le clausole dell’Annex A che mappano su un controllo in esecuzione su ogni richiesta che attraversa il gateway — accesso, crittografia e logging degli eventi — più le clausole organizzative che un proxy non può mai applicare e che deve dichiarare come gap. Questa pagina è il walkthrough iso 27001 ai: quali clausole dell’Annex A copre il pack ISO/IEC 27001, i controlli che materializza, e come le evidenze sono firmate. Per il flusso di installazione e il formato del report in profondità, segui i link in fondo — questa è la mappa specifica per 27001, non il riferimento completo della Compliance.

​
1. Cosa copre il pack iso 27001 ai

Il pack ISO/IEC 27001 mappa i controlli dell’Annex A 2022 su guardrail che girano su ogni richiesta che attraversa il gateway. Tre clausole mappano su applicazione live; due sono organizzative e sono dichiarate come gap anziché rivendicate.
Clausola Annex APianoControllo
A.9 Controllo degli accessiguardrailTieni le PII fuori dal provider upstream, coerente con il need-to-know
A.10 CrittografiaguardrailBlocca chiavi private e segreti in transito
A.12.4 Logging e monitoraggioguardrailRegistra ogni decisione del guardrail come evidenza
A.5 Controlli organizzativi e A.6 Controlli sulle persone sono clausole di governance — ownership delle policy, screening, e direzione del management. Un proxy non può applicarle, quindi il pack le fa emergere come gap dichiarati (o righe owner-attested) sia nella console che nel report, mai come copertura automatizzata. I gap onesti sono ciò che rende affidabili le righe applicate. Vedi la matrice dei controlli.
Tutti e tre i controlli applicanti girano sulla stessa macchina di Guardrails che configuri a mano. Il pack è il mapping autorato che dice quale guardrail esistente soddisfa quale clausola dell’Annex A — non porta alcun nuovo motore di runtime. Vedi Contenuti del pack per l’intera anatomia.

​
2. Installa il pack — un esempio concreto

Installare materializza il mapping in policy di guardrail reali nel tuo workspace, ciascuna taggata con la provenienza del pack. Lo fai dalla console, non da una chiave di relay: Compliance → Catalog → ISO/IEC 27001 → Install Quella è un’azione da Admin del workspace su un piano a pagamento, e il server applica entrambi. Sotto il cofano la tua sessione di console chiama: 
POST /api/compliance/packs/iso_27001/install
Non passare mai una chiave di relay sk-orca-… a una rotta di configurazione. Le rotte /api/compliance/* si autenticano con la tua sessione di console, non con la chiave di relay — solo le chiamate al modello /v1/* usano sk-orca-…. Sfogliare il catalogo, i pack installati e la readiness è gratis e aperto a ogni membro del workspace; install, go-live, report e residency sono le azioni Admin gated.
Dopo l’installazione, le righe dell’Annex A smettono di essere prosa:
Una regola di guardrail pii_block reale rifiuta in modo netto le richieste che portano dati personali (email, numeri di telefono, SSN, numeri di carta, IP) in fase di richiesta, così non raggiunge mai il provider upstream — coerente con l’accesso need-to-know. Puoi aprirla, leggerla, e regolare l’insieme di entità come qualsiasi altra regola.
Regole regex che bloccano chiavi private PEM e token cloud, stratificate con il Secrets Blocker, così il materiale crittografico non transita mai nel gateway in un prompt.
Una regola con azione flag registra ogni decisione del guardrail come evidenza senza bloccare il traffico — la clausola di logging-e-monitoraggio diventa una vera riga di log per decisione.

​
3. Prima osserva, poi vai live

Un’installazione ISO/IEC 27001 non inizia a bloccare il traffico dal primo giorno. Le installazioni atterrano in observe mode: le azioni applicanti del guardrail sono forzate a flag, così raccogli evidenze “avrebbe-bloccato” contro il traffico reale prima che qualcosa rifiuti una richiesta. Quando le evidenze sembrano giuste, un Admin del workspace promuove il pack al go-live, che ripristina le azioni dichiarate — i controlli A.9 e A.10 iniziano ad applicare, il controllo A.12.4 continua a registrare — e opzionalmente promuove la policy materializzata a default del workspace. Questa è la stessa disciplina descritta in Observe vs enforce.
L’applicazione in fase di richiesta è live oggi: una richiesta che porta PII è rifiutata prima che il modello la veda, e il logger A.12.4 segnala ogni decisione sulla richiesta. La scansione live di response / streaming è in roadmap, quindi per il lato output l’evidenza di monitoraggio A.12.4 è ciò che un auditor legge sul periodo del report.

​
4. Evidenze firmate che il tuo auditor può verificare

Il punto del pack è il report. Le evidenze ISO/IEC 27001 sono generate come un report firmato Ed25519 con un hash di contenuto SHA256, esportabile come CSV, JSON o PDF, e verificabile pubblicamente — il tuo auditor controlla la firma senza un login OrcaRouter.
Ogni riga dell’Annex A porta il suo status — covered, observe, gap o attested — e quante volte il controllo si è effettivamente attivato sul periodo. Un controllo A.9 che ha mascherato migliaia di richieste si legge diversamente per un auditor rispetto a uno con zero match, e il report mostra entrambi.
Ogni controllo materializzato registra il suo control_id (es. iso27001.access), la clausola verbatim (ISO/IEC 27001 A.9 Access control), il piano, e l’id della policy live che la applica — così l’auditor percorre clausola → controllo → policy applicante → match senza alcun passo inferito.
Recupera la chiave pubblica di firma su GET /api/public/compliance/pubkey, invia il report a POST /api/public/compliance/verify, o apri un link di condivisione per auditor con scope su GET /api/public/compliance/share/:token. Nessun account richiesto.
Vedi il report firmato per il layout da copertina a footer e Verifica un report per il walkthrough di verifica.

​
5. Region-stamp delle tue evidenze ISO 27001

I report ISO/IEC 27001 sono archiviati e serviti sotto la tua regione di residency dichiarata — us / eu / uk / ap / cn / global — e un report viene servito solo sotto una regione corrispondente; le letture cross-region vengono trattenute. Un Admin del workspace la imposta tramite PUT /api/compliance/residency.
La residency qui è la regione dell’artefatto di evidenze — dove i report firmati vivono e sono serviti. Non è geo-blocco dei dati di inferenza. Vedi Data residency e Cross-region per il confine.
I log delle richieste hanno default di retention di 30 giorni (server-clamped a un massimo massimo di 180 giorni), e una cancellazione utente esegue una finestra di grazia di 30 giorni poi uno scrub PII — entrambi rilevanti quando un auditor sonda la tua postura di retention A.12.4. Vedi Retention e Diritto alla cancellazione.

​
6. Dove andare dopo

ISO/IEC 42001

Il compagno per il sistema di gestione dell’AI — abbina lo scope ISMS del 27001 con i controlli AIMS del 42001.

Contenuti del pack

L’intera anatomia di un pack — piano, status e provenienza.

Installa un pack

Il flusso di installazione end-to-end, observe mode e go-live.

Report firmato

Cosa contiene il report di evidenze firmato Ed25519.

Guardrails

Il piano dei contenuti su cui il pack 27001 scrive — PII, segreti e logging.

Framework

L’intero catalogo — SOC 2, HIPAA, GDPR, l’EU AI Act, e altro.
ISO/IEC 27001 su un gateway hosted è la disciplina di essere precisi: mappa i controlli dell’Annex A che un proxy può applicare su guardrail live, dichiara quelli organizzativi che non può, e firma le evidenze così la linea tra le due regge all’audit.