# Data Processing Agreement (DPA)
JWC desk — versione 1, aggiornata al 30/09/2026
Il presente Data Processing Agreement (di seguito "DPA") è parte integrante dei Termini e Condizioni di Utilizzo e della Privacy Policy del Servizio JWC desk. Viene accettato dall'Utente in fase di registrazione e disciplina il trattamento dei dati personali per conto del Titolare del trattamento ai sensi del Regolamento UE 2016/679 (GDPR).
1.1 Titolare del trattamento (Cliente/Utente): il professionista o impresa che si registra al Servizio e determina finalità e mezzi del trattamento dei dati personali inseriti nella Piattaforma, inclusi i dati di propri clienti, fornitori e collaboratori.
1.2 Responsabile del trattamento (JWC desk): il fornitore del Servizio SaaS che tratta i dati personali per conto del Titolare, esclusivamente per l'erogazione del Servizio e per gli obblighi di legge connessi.
2.1 Il Responsabile tratta i dati personali per conto del Titolare al fine di erogare il Servizio SaaS di gestione finanziaria, contabile e operativa, incluse: generazione di file XML FatturaPA per l'utilizzo con il programma di fatturazione dell'Utente, gestione clienti, progetti, time tracking, rapportini di lavoro, scadenziario, spese e reportistica.
2.2 Il trattamento ha durata pari all'intero periodo di abbonamento sottoscritto dal Titolare e cessa con la cancellazione definitiva dell'account, salvo quanto previsto all'art. 10.
3.1 Il Responsabile tratta le seguenti categorie di dati per conto del Titolare:
/report/verify/{uuid} che espone nome, email, IP, user-agent del firmatario)
status=success e tentativi falliti status=failed con email_attempted)
document_acceptances con traccia d'audit in consent_events, esportabile e verificabile pubblicamente via /consent/verify/{uuid} e chiave pubblica /consent/public-key.pem.
/api/v1/*), il sistema genera Personal Access Tokens (Laravel Sanctum) su richiesta dell'Utente admin. Ogni token: stringa 64 caratteri (hash SHA-256 memorizzato, non il token in chiaro), abilities JSON per definire scopi/permessi, expires_at per scadenza configurabile, last_used_at per tracciamento utilizzo, revocabile singolarmente. Il token in chiaro è mostrato solo una volta alla creazione; l'Utente deve conservarlo in sicurezza. L'autenticazione API richiede: ruolo admin, email verificata, account non disattivato. La registrazione via API (POST /api/v1/auth/register) registra automaticamente i consensi per tutti i documenti legali pubblicati (privacy, termini, dpa, misure-sicurezza) tramite ConsentSignerService, con read_declared=true.
AdminMessage, AdminMessageRead) per comunicazioni broadcast (a tutti i tenant), per tenant specifico o per utente specifico. Ogni messaggio: contenuto, metadati (titolo, priorità, visible_to: all/tenant/user), published_at, tracking letture per utente (AdminMessageRead). Accessibili via API (/api/v1/messages/*) e web. Le notifiche email per messaggi admin usano i fornitori email transazionali già elencati (§6.2).
yearly/promo_yearly), importo precedente, nuovo importo, data decorrenza, data annuncio preavviso, superadmin creatore. Il preavviso di 30 giorni è inviato automaticamente via email (job subscription:notify-price-changes, orario 06:15) agli amministratori dei tenant con abbonamento pagato attivo (subscription_status='active' e subscription_ends_at futuro); i tenant in prova sono esclusi. Idempotenza garantita da announced_at; annullamento possibile solo se non ancora annunciato.
3.2 Gli interessati sono: il Titolare stesso, i suoi dipendenti, collaboratori, clienti, fornitori e qualsiasi altra persona fisica i cui dati siano inseriti dal Titolare nel Servizio.
4.1 Per motivi tecnici e di manutenzione, l'amministratore di sistema di JWC desk ha accesso alla gestione del database e ai dati in esso contenuti. Tale accesso è strettamente limitato alle seguenti operazioni:
4.2 Modalità di accesso:
- Log di accesso dell'applicazione (AccessLog: tenant_id, user_id, IP, user-agent, status, timestamp) - Log del server di hosting (se disponibili)
4.3 L'amministratore di sistema è vincolato al più stretto riserbo e non può in alcun caso:
5.1 JWC desk è un'architettura multi-tenant con database condiviso. L'isolamento dei dati tra diversi Titolari è garantito da:
tenant_id
tenant_id alla creazione di ogni record
Rule::exists(..., 'tenant_id') nelle validazioni dei controller
5.2 I file caricati e generati sono organizzati su filesystem per tenant, secondo le seguenti convenzioni:
storage/app/public/{dominio-tenant}/ — accessibili via web tramite symlink /storage
storage/app/private/{dominio-tenant}/ — scaricabili esclusivamente tramite route autenticate
storage/app/public/fixed-expenses/{tenant_id}/
6.1 Il Titolare autorizza il Responsabile a servirsi dei seguenti sub-responsabili:
PriceChangeNoticeMail (job subscription:notify-price-changes, 06:15) agli admin tenant paganti attivi per notifica variazioni canone (art. 4.3 Termini, preavviso 30gg); provider: Mailgun/SendGrid/Postmark/Resend/SES
6.2 Il Responsabile può servirsi di fornitori di servizi email transazionali (es. Mailgun, SendGrid, Postmark, Resend, SES) per l'invio di notifiche di servizio (OTP approvazione rapportini, rinnovo abbonamento, avviso cancellazione). Le evidenze di firma (work_report_evidences) e le evidenze di consenso (document_acceptances) sono verificabili pubblicamente tramite endpoint /report/verify/{uuid} e /consent/verify/{uuid} (espongono nome, email, IP, user-agent del firmatario/utente). I font tipografici (Inter, Manrope) sono serviti localmente (self-hosted); nessun indirizzo IP viene trasmesso a Google o ad altri terzi. Tali endpoint di verifica pubblica agiscono in qualità di destinatari per finalità di prova e interesse legittimo (Art. 6.1.f GDPR).
6.3 Il Responsabile si impegna a imporre ai sub-responsabili, mediante contratto, obblighi di protezione dei dati equivalenti a quelli del presente DPA.
6.4 Il Titolare autorizza genericamente la nomina di nuovi sub-responsabili. Il Responsabile informerà il Titolare con almeno 30 giorni di anticipo di eventuali variazioni, consentendo al Titolare di opporsi.
Il Responsabile adotta le seguenti misure di sicurezza, basate sull'architettura effettiva del sistema:
storage/app/private/consent_keys/ (non web-accessible), generata con php artisan consent:keys
abilities JSON per controllo permessi granulari; expires_at per scadenza automatica; last_used_at per audit; revoca singola via tokens()->delete() o currentAccessToken()->delete(); rate limiting su endpoint auth (5 req/min login, 3 req/min registrazione)
check.domain (isolamento sottodominio), check.consent (blocco se consenso mancante), check.profile (blocco se profilo fiscale incompleto), check.subscription (blocco se abbonamento scaduto, whitelist rinnovo/logout), Gate::before (superadmin bypass)
api.tenant (isolamento tenant), api.consent (blocco se consenso mancante), api.subscription (blocco se abbonamento scaduto); login mobile solo per admin con email verificata; registrazione API registra consensi automaticamente via ConsentSignerService; supporto multi-utente per tenant (admin + user con permessi limitati)
PriceChangeNoticeMail inviata esclusivamente agli amministratori dei tenant con abbonamento pagato attivo (subscription_status='active' e subscription_ends_at futuro); tenant in prova (trial) esclusi in quanto pagheranno il prezzo vigente al primo pagamento; idempotenza via announced_at; annullamento possibile solo se non ancora annunciato.
GET /work-reports/{id}/check-integrity con hash_equals()
GenerateSignedSnapshotPdf) e conservato immutabile su storage privato
RuntimeException su tentativo modifica)
email_verified_at e session_hash
signature_data
work_report_evidences): payload canonico JSON deterministico + firma server RSA-4096 detached + marca temporale (TSA RFC 3161 se attiva, altrimenti marca server firmata RSA-4096 fallback) + hash-chain per cliente (previous_acceptance_hash); append-only, verificabile pubblicamente via /report/verify/{uuid} (5 controlli: integrità payload, firma server, integrità rapportino, marca temporale, hash-chain)
document_acceptances): documenti versionati append-only (legal_documents) con content_hash SHA-256; evidenze solo INSERT; payload canonico; payload_hash SHA-256; firma server RSA-4096; hash-chain per utente; TSA RFC 3161 o marca server; verifica pubblica /consent/verify/{uuid} (5 controlli); chiave pubblica /consent/public-key.pem; certificato consenso PDF rigenerabile on-demand; audit trail consent_events append-only; ConsentSignerService utilizzato anche per registrazione automatica consensi alla registrazione via API (ApiAuthController::recordRegistrationConsents)
GET_LOCK/RELEASE_LOCK MySQL + lockForUpdate() per numerazione FatturaPA FPR12 concorrente; idempotenza operazioni Stripe tramite Cache::add() atomico
status=success) e tentativo fallito (status=failed con email_attempted) con tenant, utente, IP, user-agent, timestamp; conservati per durata abbonamento; in caso di disattivazione account (cancellazione logica deleted_at), i log persistono per finalità di sicurezza, audit e interesse legittimo del Titolare
stack con driver daily, rotazione 14 giorni, path storage/logs/laravel-{Y-m-d}.log, livello error in produzione / debug in sviluppo
paid_at), pro-forme (open→invoiced/cancelled/paid), pagamenti Stripe (stripe_invoice_id, stripe_customer_id, stripe_subscription_id, payment_date, next_billing_date), consenso (document_acceptances WORM + consent_events), promemoria abbonamento (soglie 30/15/7/2 giorni in subscription_reminders_sent), variazioni canone (PriceChange: creazione, annuncio preavviso announced_at, annullamento)
subscription:check-deadlines (06:00, motore scadenze no-webhook), subscription:notify-price-changes (06:15, preavviso 30gg variazioni canone), subscription:purge-expired (06:30, avviso 53gg + cancellazione 60gg), deadlines:send-reminders (08:30, promemoria scadenze); fallimento check-deadlines = incidente CRITICO (tenant restano active oltre scadenza reale)
| Livello | Descrizione | Esempio | Tempo risposta |
|---------|-------------|---------|----------------|
| CRITICO | Violazione dati personali effettiva o accesso non autorizzato confermato; fallimento job schedulato critico subscription:check-deadlines | Data breach, furto credenziali admin; job scadenze non eseguito → tenant restano active oltre scadenza reale | Immediato (entro 1 ora) |
| ALTO | Vulnerabilità critica attiva o tentativo intrusione rilevato | CVE su dipendenza critica, attacco DDoS | Entro 4 ore |
| MEDIO | Vulnerabilità potenziale o anomalie nei log | Tentativi login multipli sospetti | Entro 24 ore |
| BASSO | Evento anomalo senza impatto diretto sui dati | Configurazione non ottimale, tentativi bloccati da rate limiting | Prossimo ciclo manutenzione |
1. Rilevamento e classificazione: monitoraggio log applicativi/accesso, segnalazioni Titolari/utenti, composer audit/npm audit periodici, notifiche automatiche sicurezza → classificazione per tabella sopra → registrazione registro incidenti
2. Contenimento: accesso non autorizzato → revoca credenziali, blocco IP, forzatura logout; vulnerabilità → isolamento endpoint, patch, disabilitazione ffunzionalità ; data breach → identificazione ambito esatto, preservazione log; DDoS → rate limiting aggressivo, contatto Altervista mitigazione rete
3. Notifica: Titolare entro 48h (natura, categorie/numero interessati, conseguenze, misure rimedio); Garante Privacy entro 72h ove richiesto; interessati se rischio elevato
4. Post-incidente: analisi root cause, aggiornamento misure sicurezza, test, comunicazione esito Titolare
Il Responsabile collabora con il Titolare per adempiere agli obblighi di notifica all'autorità di controllo e comunicazione agli interessati.
9.1 Il Responsabile assiste il Titolare, per quanto possibile, nell'adempimento degli obblighi relativi a:
10.1 Alla cessazione del Servizio per qualsiasi causa, il Titolare può esportare i propri dati tramite le ffunzionalità della Piattaforma:
10.2 Ai sensi dell'art. 7.4 dei Termini e Condizioni di Utilizzo e della Privacy Policy, la conservazione dei documenti fiscali e contabili ai fini di legge è esclusivamente a carico del Titolare, che deve scaricare e archiviare regolarmente copia dei propri documenti secondo la normativa fiscale italiana (art. 2220 c.c.). La Piattaforma non svolge funzione di conservazione sostitutiva.
10.3 In caso di mancato pagamento dell'abbonamento:
PurgeExpiredTenants, controllo trial_ends_at / subscription_ends_at), non tramite eventi Stripe.
10.4 Dopo la cancellazione definitiva dell'account:
work_report_evidences) e le evidenze di consenso documentale (document_acceptances, consent_events) sono conservati per 10 anni (art. 2220 c.c., prova del consenso prestato, hash-chain per integrità catena per utente) per obbligo probatorio del Titolare; non vengono cancellati con l'account
11.1 Il Titolare ha diritto di verificare la conformità del Responsabile al presente DPA richiedendo informazioni documentali.
11.2 Data l'infrastruttura su hosting condiviso, non sono possibili audit on-site. Il Responsabile fornirà , su richiesta del Titolare, evidenze documentali delle misure di sicurezza adottate, inclusi i log di accesso disponibili.
12.1 La responsabilità del Responsabile per violazioni del presente DPA è limitata a quanto previsto dai Termini e Condizioni di Utilizzo del Servizio.
12.2 Il Titolare è l'unico responsabile della liceità del trattamento dei dati che effettua tramite la Piattaforma e dell'aver ottenuto tutti i consensi necessari dagli interessati.
13.1 Il presente DPA è regolato dalla legge italiana e dal Regolamento UE 2016/679 (GDPR).
13.2 Per qualsiasi controversia relativa al presente DPA si applica il foro competente indicato nei Termini e Condizioni di Utilizzo.
Per qualsiasi richiesta relativa al presente DPA, il Titolare può contattare il Responsabile all'indirizzo email indicato nella sezione Contatti del Servizio JWC desk.