Salta al contenuto principale

Affidabilità

Dati per il questionario di sicurezza

Risposte per procurement e valutazioni di sicurezza, tratte dalle pagine e dalla documentazione pubbliche di Capgo. Per SOC 2, ISO 27001, mappature dettagliate dei controlli e questionari compilati, usa il portale della fiducia (richiedi l'accesso tramite NDA). I report di certificazione non vengono inviati via email.

Ultimo aggiornamento: 6 ottobre 2026.

Come usare questa pagina

Ogni sezione riassume le fonti pubbliche di Capgo e, dove indicato, le risposte ai questionari dei vendor approvati (i control ID sono mostrati come tag). Consulta le fonti primarie collegate per il testo dei contratti. Per SOC 2 Type 2, ISO 27001:2022 e i PDF dei report, usa fidati di capgo.app (NDA firmato lì, non via email). Gli elementi sotto Argomenti non pubblici ti servono ancora il trust portal o security@capgo.app?

Pagine correlate: Affidabilità , Politica di sicurezza , Subresponsabili , DPA , Enterprise .

Azienda e prodotto

  • Ragione sociale: Digital Shift OÜ (registrata con n. code 14236508), Sepapaja 6, 15551 Tallinn, Estonia. I clienti fatturati negli Stati Uniti contrattualizzano con CodepushGo, LLC, una società a responsabilità limitata del Delaware, 131 Continental Dr, Suite 305, Newark, DE 19713. Note legali .
  • Prodotto: Live Update (OTA) per app Capacitor, Ionic, Cordova ed Electron, oltre a Native Build per iOS e Android su Capgo Cloud. Live Update , Native Build .
  • Open source: Plugin updater e plugin Capgo sotto licenza MPL-2.0; backend sotto AGPL-3.0 con opzione self-hosting disponibile. GitHub .
  • Opzioni di deployment: Capgo ospitato su Cloud, oltre a opzioni Enterprise ospitate, dedicate, ibride e self-hosted con licenza. Enterprise .
  • Legge applicabile: Estonia, o Delaware per i clienti di CodepushGo, LLC, ai sensi della Termini di servizio .

Risposte al questionario vendor

Chi è responsabile delle funzioni di sicurezza? OS.3
Il CEO è il responsabile designato della sicurezza delle informazioni (ISO), incaricato della policy di sicurezza, governance, strategia, gestione di minacce e vulnerabilità e incident response, con il supporto del team engineering.
Richiedete contrattualmente che tutti i fornitori effettuino controlli sui precedenti? HR.2
No. I nostri fornitori di infrastruttura effettuano controlli sul proprio personale tramite programmi certificati SOC 2 e ISO 27001, che revisioniamo annualmente. Tutto il personale Capgo viene sottoposto a controlli prima di ricevere l'accesso.
Effettuate simulazioni di phishing almeno una volta all'anno? HR.4
No. La consapevolezza del phishing è inclusa nell'onboarding e nella formazione annuale sulla sicurezza; l'MFA è obbligatorio per tutti gli account.
La restituzione degli asset e la revoca degli accessi sono documentate al termine del rapporto? HR.6
Sì. La nostra checklist di cessazione prevede la restituzione dei beni aziendali e la rimozione di ogni accesso entro 1 giorno lavorativo.

Hosting e sub-processor

L'elenco ufficiale dei sub-processor DPA, delle località di elaborazione e dei meccanismi di trasferimento si trova nella pagina dei sub-processor (non nel contatore dei sub-processor del trust portal). Gli attuali sub-processor DPA includono:

  • Supabase, Inc. (Londra, UK): database principale, autenticazione, dati account, metadati di applicazione e bundle, identificativi del dispositivo.
  • Cloudflare, Inc. (globale, inclusi USA): edge CDN, Workers, Durable Objects, R2, servizi di sicurezza, consegna Live Update.
  • Google Cloud (Hong Kong, Tokyo, Sydney, Johannesburg, Milano, Jeddah, Mumbai, Sao Paulo, Columbus): repliche di lettura del database e infrastruttura regionale.
  • Scaleway SAS (Parigi, Francia): infrastruttura Native Build, artefatti e dati del workflow.

La CI del cliente non è un sub-processor DPA di Capgo: Capgo non collega i repository GitHub del cliente né ne preleva il codice sorgente. L'automazione tipica usa la CI del cliente (ad esempio GitHub Actions) con un token Capgo API per caricare i bundle o inviare richieste di Native Build. Integrazione con GitHub Actions , Integrazione CI/CD .

Capgo utilizza inoltre servizi lato controller per la propria attività (gli esempi nella pagina dei sub-processor includono Stripe, Bento, PostHog, CodeRabbit e SonarCloud). Apple e Google sono controller indipendenti per la pubblicazione sugli store quando i clienti usano i propri account developer.

Il Pagina Trust afferma che Cloudflare, Supabase e le pipeline CI isolate applicano MFA, gestione dei secret e ambienti protetti, e che i vendor critici mantengono l'attestazione SOC 2 verificata annualmente.

Per le domande sull'hosting, preferisci l'elenco dei sub-processor rispetto alle vecchie voci sull'hosting nell'imprint, che potrebbero non riflettere i fornitori attuali.

Risposte al questionario vendor

Quale URL usano i clienti per accedere all'applicazione ospitata? HAS.7
https://console.capgo.app
Dove viene ospitato il servizio? HAS.8
Presso cloud service provider: serverless su Cloudflare Workers con Supabase PostgreSQL gestito a Londra, read replica di Google Cloud e Scaleway a Parigi per le build native. Vedi la pagina dei sub-processor per l'elenco aggiornato.
Il servizio è ospitato in strutture di colocation gestite da voi? HAS.9
No. Capgo non gestisce colocation né data center di proprietà.
Come vengono separati i dati dei clienti nel servizio multi-tenant? HAS.10
Separazione logica multi-tenant. I record del database sono isolati per organizzazione tramite PostgreSQL Row Level Security e autorizzazione basata su ruoli. I bundle sono salvati in object storage in percorsi per organizzazione e per app. I clienti possono abilitare la crittografia end-to-end dei bundle con le proprie chiavi.
Ogni cliente riceve credenziali o schemi del database separati? HAS.11
Nessun database separato per cliente. L'isolamento dei tenant è garantito da Row Level Security e dall'autorizzazione applicativa, anziché da credenziali database per singolo tenant.
In che modo gli amministratori gestiscono la produzione? HAS.21
Tramite le console web dei cloud provider e le relative CLI e API su TLS, con account protetti da MFA e token API con permessi limitati. Il database di produzione e l'accesso SSH non sono esposti su internet.
Quali controlli di produzione comuni mancano? HAS.28
Non utilizziamo un SIEM dedicato o una VPN aziendale. Cloudflare offre protezione DDoS e un web application firewall all'edge, gli host di produzione sono deny-by-default e l'accesso amministrativo passa da console del provider protette da MFA.
I database girano con account di servizio non privilegiati? HAS.31
Sì. Il database è un PostgreSQL gestito da Supabase. Le connessioni dell'applicazione utilizzano ruoli dedicati non-superuser e l'accesso per gli utenti è soggetto a Row Level Security.
Il tier applicativo gira sotto un account di servizio non privilegiato? HAS.32
Sì. Il web tier gira su Cloudflare Workers in isolati V8 sandboxed, senza alcun sistema operativo o account root esposto alla nostra code.
Disponete di una policy di sicurezza fisica? PE.1
Sì, revisionata e approvata annualmente. Capgo non ha uffici o data center. La policy copre il lavoro remoto, gli endpoint e la supervisione delle strutture dei nostri cloud provider.
Quali controlli fisici proteggono il vostro ambiente? PE.2
Capgo non ha uffici o data center. La produzione gira interamente su Cloudflare, Supabase, Google Cloud e Scaleway, le cui strutture sono protette da controlli fisici verificati tramite audit indipendenti che revisioniamo annualmente.
È consentito l'accesso ai visitatori nelle vostre strutture? PE.4
Non applicabile a Capgo. Operiamo interamente in remoto senza sedi fisiche. I controlli di accesso ai data center sono gestiti dai nostri cloud provider.

Residenza e regioni dei dati

Per il piano standard Capgo Cloud, Supabase gestisce il database principale, l'autenticazione, i dati dell'account, i metadati di app e bundle e gli identificativi dei dispositivi a Londra, nel Regno Unito. Google Cloud fornisce le read replica del database e l'infrastruttura regionale a Hong Kong, Tokyo, Sydney, Johannesburg, Milano, Jeddah, Mumbai, Sao Paulo e Columbus. Lo storage dei bundle e la consegna dei Live Update utilizzano l'infrastruttura globale di Cloudflare, inclusi gli USA. Il piano Enterprise può utilizzare il routing regionale degli endpoint per il percorso Live Update o un deployment self-hosted con licenza quando è richiesto un controllo maggiore. L'elenco aggiornato dei sub-processor contiene i dettagli completi su provider, posizione e trasferimenti.

Percorso dati plugin EU (opt-in): Imposta updateUrl, statsUrl, e channelUrl ai completi endpoint EU: https://plugin.eu.capgo.app/updates, https://plugin.eu.capgo.app/stats, e https://plugin.eu.capgo.app/channel_self. Tutti e tre devono essere impostati insieme affinché i dati Live Update correlati siano memorizzati in Europa. Documentazione sulla posizione dei dati .

Dati dell'account e della console: La documentazione pubblica descrive l'opzione EU per il percorso dei dati del plugin. Un'opzione separata solo UE per i dati dell'account o della console non è documentata pubblicamente (vedi lacune ).

Residenza rigorosa: Il self-hosting con licenza dà controllo su infrastruttura, log, retention e confini di rete. Opzioni di deployment conformi a HIPAA .

Crittografia

  • In transito: HTTPS/TLS per la trasmissione dei dati. Documentazione di compliance , DPA .
  • A riposo: Crittografia a riposo per i dati della piattaforma dove applicabile, secondo la documentazione di compliance e le misure di sicurezza del DPA.
  • Crittografia bundle opzionale (chiavi cliente): Crittografia end-to-end dei bundle con chiavi gestite dal cliente (RSA-4096 e AES-256-GCM in Encryption V2). Documentazione sulla crittografia . Protegge dalla divulgazione da parte di Capgo, provider di storage e CDN; non rende impossibile il reverse engineering degli asset web distribuiti.
  • Integrità: I bundle sono verificati tramite checksum; crittografia opzionale per app con la propria chiave. Documentazione di compliance .
  • Chiavi API: Le chiavi API sicure sono hashate; il valore della chiave in chiaro non è memorizzato sui server Capgo. Documentazione sulla sicurezza dell'organizzazione .

Risposte al questionario vendor

I dati dei clienti sono crittografati a riposo nei database e nell'object storage? HAS.13
Sì. Database, backup e object storage sono criptati a riposo con AES-256 dai nostri cloud provider, con chiavi gestite e ruotate nei loro sistemi di key management. I clienti possono inoltre criptare i bundle end-to-end con la propria coppia di chiavi.
Ogni cliente ha una chiave di cifratura distinta per lo storage della piattaforma? HAS.14
No per lo storage della piattaforma. Le chiavi gestite dal provider sono condivise tra i tenant. Per i bundle, i clienti possono abilitare la cifratura end-to-end con la propria coppia di chiavi RSA, la cui chiave privata Capgo non possiede mai.
Il personale che accede ai dati di produzione criptati può ottenere le chiavi di cifratura? HAS.15
No per le chiavi della piattaforma. Le chiavi di cifratura per i dati a riposo sono conservate nei sistemi di key management dei nostri cloud provider e non sono accessibili al personale Capgo. Le chiavi private per la cifratura end-to-end dei bundle sono in possesso solo del cliente.
I clienti possono fornire chiavi gestite autonomamente per la crittografia dello storage della piattaforma? HAS.16
No per lo storage della piattaforma. I clienti possono criptare i bundle end-to-end con la propria coppia di chiavi, in modo che Capgo non detenga la chiave per quel contenuto.

Autenticazione e controllo degli accessi

Controllo del cliente

  • SSO (SAML 2.0): Piani Enterprise; verifica del dominio tramite DNS TXT; SSO opzionale; i nuovi utenti SSO ricevono il ruolo di sola lettura. Documentazione SSO Enterprise .
  • MFA: I super admin dell'organizzazione possono richiedere il 2FA per tutti i membri; i membri senza 2FA sono bloccati dal web dashboard e da CLI. Documentazione sulla sicurezza dell'organizzazione .
  • Policy della password: Lunghezza minima configurabile (da 6 a 128), requisiti per maiuscole, numeri e caratteri speciali.
  • Chiavi API: Imposizione di chiavi sicure (hashed) e scadenza opzionale (da 1 a 365 giorni).
  • RBAC: Ruoli organizzativi (super admin, admin, billing admin, member) e ruoli app (admin, developer, uploader, reader) con override per canale. Documentazione delle funzionalità .

Personale Capgo

L'accesso è limitato al personale autorizzato necessario per supporto, prevenzione abusi e affidabilità operativa; il personale è formato sul GDPR e sulla privacy dei dati secondo il DPA .

I flussi di aggiornamento di password ed email possono dipendere dalla sessione di Supabase Auth e dalle impostazioni di re-verifica. Policy di sicurezza .

Risposte al questionario vendor

È richiesto una VPN per l'accesso remoto alla vostra rete? AC.11
No. Non esiste una rete aziendale a cui connettersi. Lo staff gestisce la produzione tramite console e API dei cloud provider via TLS con MFA obbligatorio. Il database di produzione e l'accesso SSH non sono esposti su internet.
Il blocco automatico dello schermo con re-autenticazione tramite password è obbligatorio entro 15 minuti o meno? AC.12
Sì. Il blocco automatico dello schermo con riautenticazione tramite password è imposto e monitorato su tutti gli endpoint tramite il nostro agente di device compliance.
L'accesso è gestito tramite controlli basati sui ruoli e sul principio del minimo privilegio, con approvazione preventiva all'emissione delle credenziali? AC.13
Sì. L'accesso è gestito tramite controllo degli accessi basato sui ruoli secondo il principio del minimo privilegio e richiede un'approvazione prima dell'emissione delle credenziali.
L'accesso viene revisionato quando un utente cambia ruolo? AC.14
Sì. La nostra piattaforma di monitoraggio della compliance avvisa il responsabile della sicurezza di aggiornare l'accesso ad ogni cambio di ruolo; inoltre, tutti gli accessi sono revisionati periodicamente.
Esiste una password policy conforme agli standard di settore, gestita dal team security e approvata annualmente? AC.15
Sì. La nostra policy documentata su password e login è gestita dall'Information Security Officer e viene revisionata e approvata annualmente dal senior management.
Gli utenti devono resettare o impostare la propria password al primo accesso? AC.16
Sì. Non emettiamo password iniziali riutilizzabili. I nuovi utenti ricevono un invito monouso o una credenziale temporanea e devono impostare la propria password al primo accesso, con obbligo di MFA.
Le password iniziali o i link di invito sono generati casualmente e sono univoci per ogni utente? AC.17
Sì. I link di invito e le credenziali temporanee sono generati casualmente e sono unici per ogni utente.
Gli account e le impostazioni predefinite del vendor vengono modificati prima dell'uso in produzione? AC.18
Sì. La produzione gira su servizi serverless gestiti senza account predefiniti del vendor; le impostazioni di default vengono revisionate e messe in sicurezza tramite i nostri controlli di configuration management prima dell'uso.
Utilizzate un servizio di directory centralizzato per l'identità del personale? AC.22
Sì. Google Workspace è la nostra directory centrale, con la Verifica in 2 passaggi obbligatoria per tutti gli account, ed è utilizzato per l'accesso ai sistemi core dove supportato.
Le password scadono secondo una pianificazione fissa? AC.23
Nessuna rotazione fissa. Seguendo lo standard NIST SP 800-63B, le password non vengono ruotate a intervalli prestabiliti. Vengono cambiate in caso di qualsiasi segnale di compromissione e l'MFA è obbligatorio su tutti i sistemi.
Le password del personale richiedono almeno 8 caratteri con maiuscole, minuscole, numeri e caratteri speciali? AC.24
Sì per gli account aziendali tramite le impostazioni del nostro identity provider, con MFA obbligatorio su tutti i sistemi.
È applicata la cronologia delle password? AC.25
Nessuna regola fissa sulla cronologia delle password del personale. Il rischio di riutilizzo è mitigato dall'uso di MFA su tutti i sistemi e di password univoche generate da un password manager.
Le password comuni vengono bloccate automaticamente? AC.25.1
Sì. Il nostro identity provider rifiuta le password deboli e comuni.
Solo i dispositivi registrati e conformi possono accedere ai sistemi interni? AC.29
Non esiste una rete aziendale. Ai sistemi interni si accede solo tramite endpoint inventariati e registrati che superano i controlli di conformità su crittografia, protezione malware, patching e blocco schermo.
Gli account inattivi vengono disabilitati automaticamente? AC.30
Non è previsto un timer di inattività. L'accesso viene rimosso entro 1 giorno lavorativo dal processo di offboarding, e revisioni periodiche dell'Information Security Officer identificano e rimuovono gli account inutilizzati.
L'MFA è obbligatorio per tutto il personale con accesso amministrativo remoto alla produzione? HAS.20
Sì. L'MFA è obbligatorio per tutti gli account del personale con accesso alla produzione e ad altri sistemi critici.
L'MFA è disponibile e applicabile per tutti gli utenti delle applicazioni Capgo Cloud? HAS.20.1
Sì. L'MFA tramite TOTP è disponibile per ogni utente; gli amministratori dell'organizzazione possono renderlo obbligatorio per tutti i membri, bloccando l'accesso al dashboard e a CLI per chiunque non abbia l'MFA attivo.
Quali metodi di accesso supporta la console Capgo Cloud? HAS.27
Gli utenti effettuano l'accesso tramite email, password e TOTP MFA, che i clienti possono imporre per tutti i membri. Il SAML 2.0 SSO con applicazione opzionale è disponibile nel piano Enterprise. L'accesso a CLI e CI utilizza chiavi API con scope e possibilità di imporre una scadenza.
Gli account vengono bloccati dopo un numero fisso di tentativi di login falliti? HAS.35
Non è previsto alcun blocco fisso per account. I tentativi di accesso sono soggetti a rate limiting da parte del nostro provider di autenticazione; i clienti possono imporre MFA o SAML SSO per tutti i propri utenti.
Il personale con privilegi ha accesso diretto al database di produzione? HAS.30
Sì, ma in modo limitato. L'accesso diretto al database di produzione è riservato a 2 ingegneri autorizzati, protetto da MFA, non esposto su internet e sottoposto a revisione periodica.
Il vostro inventario degli asset identifica i sistemi esposti su internet? AM.2.1
Sì. Il nostro inventario dell'infrastruttura e il diagramma dell'architettura identificano tutti gli endpoint esposti su internet.
Lo smaltimento sicuro di dati e supporti è regolato da protocolli formali? AM.3
Sì. Lo smaltimento segue la nostra Data Classification, Retention, and Deletion Policy. La distruzione dei supporti di memorizzazione nei data center è eseguita dai nostri cloud provider sotto i loro controlli certificati.
I baseline di configurazione della sicurezza sono definiti e revisionati almeno ogni 12 mesi? AM.5
Sì. I baseline di configurazione per i nostri servizi cloud e endpoint sono definiti secondo i nostri controlli di configuration management e revisionati almeno annualmente in linea con le nostre policy.
Gli sistemi operativi sono protetti rispetto alle porte, ai protocolli e ai servizi necessari? AM.6
Sì per la produzione: serverless su piattaforme gestite con ingress limitato a HTTPS su endpoint designati e regole firewall deny-by-default. I runner macOS di Scaleway sono il principale OS su cui Capgo opera per i Native Build.
Quali protezioni endpoint sono implementate sui dispositivi dello staff? CO.4
Tutti gli endpoint utilizzano protezione malware e full-disk encryption, monitorati dal nostro agente di device compliance. Host IPS e blocco porte USB non sono implementati. I dati dei clienti sono elaborati nei nostri sistemi cloud di produzione.
La full-disk encryption è implementata sugli endpoint dello staff? CO.5
Sì. Su tutti gli endpoint è applicata e monitorata la crittografia dell'intero disco. Database e backup cloud sono crittografati a riposo presso i nostri provider. Non scriviamo backup su supporti rimovibili.
Utilizzate strumenti DLP per monitorare il traffico in uscita e le USB? CO.5.1
No. I dati dei clienti risiedono in sistemi cloud con controllo degli accessi, gli endpoint sono completamente crittografati e monitorati, e le regole di gestione dati sono definite nelle nostre policy di Data Classification e Acceptable Use.
Le regole del firewall vengono revisionate o ricertificate regolarmente? CO.8
Sì. Le regole di ingresso in produzione sono deny-by-default e limitate agli endpoint HTTPS, e vengono revisionate almeno annualmente come parte dei nostri audit di configurazione e accesso.
Mantenete diagrammi di rete che mostrino le connessioni in entrata e in uscita? CO.9
Sì. I nostri diagrammi di rete e architettura mostrano i confini del sistema e le connessioni tra Capgo, i nostri cloud provider e i clienti, e sono aggiornati insieme all'inventario di sistema.
Il personale può leggere le email aziendali su computer personali? CO.14
Il personale può usare laptop personali registrati e iscritti al nostro agente di compliance dei dispositivi, che impone crittografia del disco, protezione malware, blocco schermo e patching. L'accesso alle email richiede MFA.
L'MFA è richiesta per l'accesso remoto alla posta aziendale? CO.15
Sì. La verifica in due passaggi è obbligatoria a livello di dominio per tutti gli account Google Workspace.
Con quale frequenza gli utenti devono riautenticarsi con MFA? CO.16
L'MFA è richiesta a ogni nuovo accesso e su qualsiasi nuovo dispositivo. La durata della sessione segue l'impostazione di controllo delle sessioni di Google Workspace (attualmente 14 giorni per le sessioni fidate).

Logging, monitoraggio e incidenti

  • Audit log del cliente: Traccia di audit per login, modifiche ai permessi, bundle, channel e modifiche all'organizzazione. Documentazione delle funzionalità Il piano Enterprise include audit logs, statistiche dell'organizzazione e log dei dispositivi per 90 giorni, come indicato nella pagina Enterprise.
  • Monitoraggio: Runbook dedicati, monitoraggio 24/7 e playbook per l'incident response guidati dai founder, come indicato nella Pagina Trust .
  • Stato: Uptime pubblico e incidenti su stato dell'app capgo (citato nella policy di supporto) ).
  • Notifica violazione dati personali (processor): Notifica i clienti senza ritardo ingiustificato, entro 48 ore dalla scoperta, via email con aggiornamenti periodici, come indicato nel DPA .
  • Fail-safe dell'updater: Se il servizio di aggiornamento non risponde entro 3 secondi, il plugin annulla la richiesta e avvia l'app normalmente secondo la policy di supporto .

Risposte al questionario vendor

I log di audit vengono conservati per almeno tre anni? AC.26
No. Gli eventi di audit vengono generati per azioni di sicurezza su sistemi critici e monitorati tramite alert per rilevare attività anomale. I log sono conservati secondo la nostra Logging Policy e le impostazioni di retention di ogni piattaforma, che sono inferiori a tre anni.
I log di produzione alimentano un SIEM? AC.27.1
Nessun SIEM dedicato. I log di produzione sono raccolti tramite gli strumenti di logging e observability dei nostri cloud provider con alert attivi, e vengono revisionati per rilevare attività anomale.
Quali difese di rete e monitoraggi sono attivi? CO.3
Cloudflare offre edge firewall, web application firewall e protezione DDoS. Gli host di produzione usano regole deny-by-default e Google Workspace filtra email e spam. Non gestiamo un SIEM dedicato; i log sono monitorati con alerting negli strumenti dei nostri provider.
Il vostro piano di incident response copre i tipi di incidente più comuni? IE.2
Sì. Il nostro piano di incident response copre malware, denial of service, accessi non autorizzati, accessi fisici non autorizzati, perdita di dati, laptop smarriti e ransomware. Gli scenari di intrusione fisica si applicano solo agli endpoint, perché operiamo completamente in remoto senza sedi di proprietà.
Avete una società di incident response con contratto continuativo? IE.3
Nessun retainer attivo. Il nostro piano di incident response prevede l'ingaggio di una società esterna specializzata in caso di necessità.
Il piano di incident response viene testato e aggiornato almeno una volta all'anno? IE.3.2
Sì. Il piano di incident response viene rivisto e approvato annualmente dal senior management e svolgiamo un'esercitazione tabletop ogni anno.
Esiste un protocollo per coinvolgere le forze dell'ordine? IE.6
Sì. La nostra policy di incident response definisce le modalità di notifica ai clienti e agli altri stakeholder; inoltre, manteniamo i contatti con le autorità competenti, incluse le forze dell'ordine, come parte del nostro programma ISO 27001.

Backup, disponibilità e SLA

  • Backup, ridondanza, crittografia e controlli di accesso secondo DPA le misure di sicurezza.
  • Replicazione regionale e read replica secondo la documentazione Enterprise e dei sub-processor.
  • SLA uptime Enterprise: 99.9% mensile con service credit dal 10% al 30%. SLA .

I backup vengono testati periodicamente per integrità e ripristinabilità, con procedure di recovery esercitate annualmente (vedi risposte al questionario vendor sotto). Gli obiettivi specifici di RPO e RTO non sono pubblicati su capgo.app.

Risposte al questionario vendor

Are backup recoveries tested at least annually? CO.6
Sì. I backup vengono testati periodicamente per verificarne l'integrità e la ripristinabilità, e le procedure di recovery vengono esercitate annualmente.

Gestione e disclosure delle vulnerabilità

  • Scanning Code: SonarCloud e Snyk; i problemi critici vengono bloccati dalla produzione in base a Pagina Trust e documentazione di compliance .
  • Review delle pull request: Revisione di CodeRabbit AI sulle pull request in base alla documentazione di compliance.
  • Penetration testing: Penetration testing indipendente come indicato nella pagina Trust. Fornitore, data e report non sono pubblici; usa il trust portal per richiedere le evidenze.
  • Target di patching: Criticità entro 7 giorni e alta entro 30 giorni, secondo la nostra Vulnerability Management Policy (vedi risposte al questionario vendor sotto).
  • Disclosure: Segnala tramite Avvisi di sicurezza GitHub (anche capacitor-updater e CLI tramite security.txt ). Risposta entro 7 giorni lavorativi secondo la policy di sicurezza . Report a pagamento tramite bug bounty .

Risposte al questionario vendor

Quali test di sicurezza sono richiesti prima del rilascio in produzione? HAS.4
Ogni pull request esegue test automatizzati, linting, analisi statica (SonarCloud e uno scan di sicurezza obbligatorio) e una revisione automatizzata di code prima del merge; le modifiche in produzione sono approvate dal management. Il DAST non fa parte della release pipeline. Un penetration test annuale effettuato da terze parti copre l'applicazione in esecuzione.
Qual è la cadenza di patching per vulnerabilità critiche e alte? VM.7
Critiche: entro 7 giorni. Alte: entro 30 giorni, come previsto dalla nostra Vulnerability Management Policy.

Certificazioni e come richiedere le prove

Le dichiarazioni pubbliche includono:

  • SOC 2 Type 2 completato (Type II) secondo la documentazione di compliance .
  • Certificazione ISO 27001:2022 secondo la documentazione di compliance e il trust portal.
  • Badge del trust portal per SOC 2 Type 1, SOC 2 Type 2, SOC 3, ISO 27001 e GDPR su fiducia.capgo.app .

Come ricevere i report: Vai su fiducia.capgo.app , usa Request Access per report SOC, prove ISO, questionari di sicurezza e dettagli sui controlli sotto NDA. Non verranno inviati PDF di certificazione via email.

I pacchetti per la revisione della sicurezza Enterprise possono includere un report SOC 2, un modello DPA e note sull'architettura secondo il pagina Enterprise , sempre tramite il portale trust per le prove formali.

I report completi di audit SOC 2 e ISO, le opinioni dei revisori e il dettaglio dello scope sono disponibili solo tramite il portale trust. Le pagine marketing pubbliche non riproducono i PDF dei report.

Risposte al questionario vendor

Esiste un processo di non ritorsione per la segnalazione di compliance interna? CP.3
Sì. Il personale può segnalare eventuali criticità tramite i canali di reporting definiti nelle nostre policy, e il nostro Code di Business Conduct tutela chi segnala in buona fede da qualsiasi ritorsione.
I contratti con i vendor includono clausole di sicurezza? OS.7
Sì. Gli accordi con i nostri provider di infrastruttura e i DPA coprono i controlli di accesso, la notifica di data breach, la sicurezza dei sub-processor e la proprietà dei dati. I diritti di audit sono esercitati tramite i loro report indipendenti SOC 2 e ISO 27001.
Effettuate la due diligence sulla sicurezza dei vendor? OS.8
Sì. I vendor vengono identificati e valutati in base al rischio durante una risk assessment annuale che esamina le loro attestazioni di sicurezza, inclusi controlli di accesso, MFA e crittografia, con impegni sulla sicurezza e notifiche di incidenti nei contratti.
Esiste un processo definito per le eccezioni alle policy di sicurezza? SP.4
Sì. Le eccezioni sono documentate, sottoposte a valutazione del rischio, approvate e tracciate secondo la nostra Policy Management and Exception Handling.
Disponete di una cyber insurance? RM.5
Nessuna polizza cyber insurance al momento.

Privacy e DPA

  • DPA: Accettato automaticamente usando il prodotto; il cliente è il controller, Capgo è il processor; SCC con sub-processor; obblighi di notifica breach e assistenza. DPA (ultimo aggiornamento 10 giugno 2026 sulla pagina inglese).
  • DPA / NDA firmati: Available on Enterprise per the Enterprise page.
  • Dati raccolti dall'updater (default): App ID, versioni, piattaforma, device ID app-scoped, bundle, channel, OS, versione plugin, paese della richiesta e IP. Capgo non raccoglie nomi, email o advertising ID di default. Opzionale custom_id e statistiche metadata possono contenere identificativi personali se la tua app li invia. Le deployment HIPAA-minimum dovrebbero omettere tali campi e disabilitare allow_device_custom_id. L'ID del dispositivo è un dato personale pseudonimo soggetto al GDPR. Documentazione di compliance .
  • Disabilita le statistiche esplicite: Imposta statsUrl una stringa vuota per interrompere l'invio delle statistiche esplicite. Quando updateUrl rimane attivo, Capgo può ancora memorizzare i dati su MAU, inventario dispositivi e decisioni di aggiornamento necessari per i Live Update e la fatturazione. Documentazione sulla conformità HIPAA .
  • Retention: Ritenzione dei bundle configurabile; i log operativi sono conservati per finalità di servizio, sicurezza, fatturazione e supporto, senza un periodo di conservazione pubblico predefinito.
  • Nessuna vendita di dati del servizio: Specificato nel DPA e Politica sui dati .

Vedi anche Informativa sulla privacy e Subresponsabili (avviso di modifica a 30 giorni).

Deployment sensibili HIPAA

Il cloud di Capgo è hai attualmente configurato come processore di statistiche ospitato conforme a HIPAA secondo la documentazione sulla conformità HIPAA . I piani Enterprise possono includere un Business Associate Agreement (BAA) per clienti del settore sanitario secondo la pagina sulla conformità HIPAA .

Le opzioni di deployment per revisioni più stringenti includono endpoint EU, disattivazione delle statistiche esplicite (con i limiti sopra indicati), statistiche self-hosted e licenze per self-hosting (vedi la pagina sulla conformità HIPAA).

AI Generativa

Di default, Capgo non invia dati dei clienti ad alcun provider AI. Lo sviluppo interno può utilizzare assistenti di coding AI solo sul code sorgente di Capgo. Se un cliente sceglie la diagnostica dei build-log, quei log vengono elaborati su richiesta da Cloudflare Workers AI (vedi la pagina dei sub-processor ), senza alcuna ritenzione da parte del servizio AI e senza uso per il training.

Risposte al questionario vendor

Utilizzate strumenti di AI generativa pronti all'uso che potrebbero elaborare dati dei clienti? GAI.2
Di default, i dati dei clienti non vengono elaborati da strumenti di AI generativa pronti all'uso. Capgo utilizza assistenti di coding AI solo per lo sviluppo sul proprio code sorgente di Capgo, non sui dati dei clienti. L'unica eccezione rivolta al cliente è la diagnostica opzionale dei build-log: quando un cliente accetta, quei log vengono elaborati su richiesta da Cloudflare Workers AI, un sub-processor elencato, senza alcuna ritenzione da parte del servizio AI e senza uso per il training dei modelli.
I dati dei clienti vengono inviati all'esterno del vostro ambiente per l'analisi tramite AI? GAI.3
Per impostazione predefinita, i dati dei clienti non vengono inviati ad alcun provider AI esterno per l'analisi. L'unica eccezione riguarda la diagnostica opzionale dei build-log: se il cliente acconsente, tali log vengono elaborati su richiesta da Cloudflare Workers AI (elencati nella nostra pagina dei sub-processor), senza alcuna conservazione da parte del servizio AI e senza alcun uso per l'addestramento dei modelli.
Verificate che gli output dell'AI non producano risultati ingiusti o discriminatori? GAI.10
Non applicabile. L'IA viene utilizzata solo per la diagnostica tecnica dei build-log e per l'assistenza allo sviluppo interno, senza prendere decisioni riguardanti singoli individui.
L'elaborazione tramite AI evita di fare affidamento su caratteristiche protette? GAI.11
Sì. La funzione AI rivolta al cliente elabora solo build-log tecnici e non utilizza dati personali o caratteristiche protette.
L'output dell'AI è gestito tramite revisione e monitoraggio umano? GAI.12
Sì. L'output AI per il cliente ha solo scopo consultivo ed è mostrato al developer, che decide come procedere. Non vengono intraprese azioni automatizzate. La funzione è opzionale (opt-in) e coperta dai nostri processi di valutazione del rischio e vendor management.
Is access to AI components least privilege? GAI.13
Sì. La funzione AI gira all'interno della nostra piattaforma di produzione sotto gli stessi controlli di accesso basati sui ruoli e sul principio del minimo privilegio; il servizio del modello non memorizza i dati dei clienti.
Mantenete un inventario di modelli AI, fonti dati e componenti? GAI.15
Sì. I nostri inventari di vendor e sistemi elencano il servizio AI, i modelli utilizzati e le fonti dati che lo alimentano.
Per quanto tempo i dati inseriti dai clienti vengono conservati nel sistema AI? GAI.16
Di default, nessun contenuto del cliente viene inviato al servizio AI. Quando un cliente sceglie la diagnostica dei build log, i log vengono elaborati su richiesta da Cloudflare Workers AI e non vengono conservati dal servizio né usati per l'addestramento dei modelli. I build log salvati nei sistemi Capgo seguono la nostra standard data retention policy.

Contatti

Argomenti non dichiarati pubblicamente

Di seguito sono riportate domande comuni nei questionari a cui non si risponde sulle pagine pubbliche di Capgo. Richiedi dettagli tramite il trust portal o scrivendo a security@capgo.app.

  • Periodo del report SOC 2, ambito e dettagli della lettera dell'auditor oltre quanto fornito dal trust portal
  • Fornitore penetration test, data e lettera di sintesi (i test annuali sono confermati in Vulnerability management)
  • Target numerici RPO e RTO pubblicati
  • Periodi esatti di retention dei log per sistema, oltre al riepilogo di meno di tre anni in Logging, monitoring, and incidents
  • Versione minima TLS, cipher suites e dettagli sulla rotazione del key management della piattaforma
  • Provisioning SCIM
  • Contatto del Data Protection Officer o del rappresentante UE
  • Tempistiche di eliminazione dei dati dei clienti dopo la cessazione del contratto
  • Certificazioni PCI DSS, FedRAMP, CSA STAR o TISAX (non dichiarate pubblicamente)