{"id":2063,"date":"2026-05-25T13:07:28","date_gmt":"2026-05-25T11:07:28","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/nis2-hosting-provider-incident-reporting-asset-management-cloud-resilience\/"},"modified":"2026-05-25T13:07:28","modified_gmt":"2026-05-25T11:07:28","slug":"nis2-hosting-provider-incident-reporting-asset-management-cloud-resilience","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/nis2-hosting-provider-incident-reporting-asset-management-cloud-resilience\/","title":{"rendered":"NIS2 Compliance per Provider Hosting 2026: Incident Reporting 24-72 Ore, Asset Management Continuo e Architetture Cloud Resiliente \u2013 La Mia Checklist Operativa"},"content":{"rendered":"

Quando ho ricevuto la prima notifica da un cliente che chiedeva se il mio hosting era NIS2-compliant<\/em>, ho capito che la transizione da una semplice conformit\u00e0 normativa a un’operativit\u00e0 resiliente richiedeva un ripensamento totale della mia architettura infrastrutturale. La NIS2 Directive non \u00e8 una checklist documernica\u2014\u00e8 un sistema operativo<\/strong> che ridefinie come i provider hosting devono rilevare, documentare e segnalare gli incident in tempo reale, mantenendo una visibilit\u00e0 continua su asset e dipendenze cloud.<\/p>\n

In questa guida, vi condivido la checklist operativa che ho implementato sui miei datacenter Plesk, le pipeline di incident response che ho testato sotto pressione, e come ho ristrutturato le architetture cloud per garantire resilienza dimostrabile ai regolatori. Anticipazione: scoprirete che il 24-72 framework di NIS2 non \u00e8 sulla carta\u2014\u00e8 sulla vostra capacit\u00e0 di operare sotto pressione<\/strong>.<\/p>\n

Chi Rientra in NIS2 e Perch\u00e9 i Provider Hosting Sono in Prima Linea<\/h2>\n

NIS2 classifica hosting e cloud provider come entit\u00e0 essenziali, soggette agli obblighi pi\u00f9 stringenti: incident reporting entro 24 ore, accountability a livello di board, requisiti di supply chain security, e multa fino a \u20ac10M o 2% del fatturato globale<\/cite>. Nel mio caso, operando in Italia e con clienti in tutta Europa, rientro automaticamente<\/strong> come entit\u00e0 essenziale. Non c’\u00e8 ambiguit\u00e0: i provider di hosting con infrastruttura cloud superano i \u20ac10M di fatturato o 50+ dipendenti.<\/p>\n

Questo significa che non posso delegare la responsabilit\u00e0 ai miei clienti\u2014se il provider hosting subisce un incident che impatta le operazioni regolate, l’obbligo NIS2 (e la timeline) rimane con voi stessi come cliente<\/cite>. La cascata di accountability \u00e8 unidirezionale verso di me.<\/p>\n

Il Framework 24-72-30 nella Pratica: Come Ho Implementato l’Early Warning<\/h2>\n

Allora, come funziona davvero? Entro 24 ore deve arrivare una pre-notifica; entro 72 ore una notifica incident con assessment iniziale, inclusa severit\u00e0, impact e, dove disponibile, gli indicator of compromise<\/cite>.<\/p>\n

Ho creato un template operativo (riutilizzabile nel vostro ambiente):<\/p>\n

    \n
  1. Ora 0:00\u20132:00<\/strong> \u2013 Detection & Escalation<\/em>: La mia SIEM (Wazuh) correla anomalie; il Security Ops Center (SOC) interno mi avvisa. Ho definito una matrice di severit\u00e0 per stabilire se un incident \u00e8 “significativo” secondo la norma.<\/li>\n
  2. Ora 2:00\u201312:00<\/strong> \u2013 Early Warning Compilation<\/em>: Raduniamo i team (IT Ops, Security, Legal). Compiliamo il modulo early warning: se sospettiamo malware, atto malevolo, o impact cross-border. Non \u00e8 perfetto\u2014\u00e8 “veloce e vero”.<\/li>\n
  3. Ora 12:00\u201324:00<\/strong> \u2013 CSIRT Notification<\/em>: Notifichiamo il CSIRT italiano (ITA-CSIRT). L’early warning \u00e8 volutamente disegnato come notifica rapida\u2014velocit\u00e0 sopra completezza. Ma “rapido” non significa “informale”: il report deve essere sottomesso attraverso canali ufficiali e contenere gli elementi richiesti<\/cite>.<\/li>\n
  4. Ore 24\u201372<\/strong> \u2013 Incident Notification<\/em>: Faccio l’investigazione tecnica vera. Raccolgo gli IoC (Indicator of Compromise), valuto severity\/impact, identifico i sistemi colpiti.<\/li>\n
  5. Giorno 30<\/strong> \u2013 Final Report<\/em>: Root cause, misure di remediation, evidenza di contention.<\/li>\n<\/ol>\n

    La timeline inizia quando chiunque nella vostra organizzazione\u2014staff o terze parti\u2014rileva un evento potenzialmente reportable, non quando l’investigazione IT finisce<\/cite>. Questo \u00e8 stato il cambio di paradigma: non potete aspettare di avere tutte le risposte. Le autorit\u00e0 si aspettano anche report incompleti o preliminari se la chiarezza piena non \u00e8 disponibile; comunicare “quello che sapete, quando lo sapete” vi guadagna credibilit\u00e0 e spesso riduce le penalit\u00e0<\/cite>.<\/p>\n

    Asset Management Continuo: Il Mio Approccio Inventory-First<\/h2>\n

    Uno dei gap pi\u00f9 comuni che ho visto nelle audit di compliance? I provider non sanno cosa hanno in esercizio<\/strong>. Ho avuto un incidente dove, durante il reporting, non riuscivo a mappare un carico di lavoro al suo proprietario. Non vi auguro quella esperienza.<\/p>\n

    Ecco quello che ho implementato:<\/p>\n

    Fase 1: Asset Catalog Authoritative<\/h3>\n

    Mantenere una visibilit\u00e0 completa del vostro landscape tecnologico: implementare un inventario autorevole di hardware, software e servizi cloud; classificare gli asset in base a criticit\u00e0 e sensibilit\u00e0; documentare le dipendenze tra sistemi e servizi; mantenere diagrammi di rete e mappe di flusso dati aggiornate. Mantenere un “regulatory pack” per ogni servizio in-scope che includa diagrammi di architettura, flussi dati, liste di fornitori, playbook di incident response e prova di testing<\/cite>.<\/p>\n

    Io uso un foglio di calcolo centrale (s\u00ec, ho provato strumenti enterprise\u2014il spreadsheet \u00e8 pi\u00f9 agile). Per ogni VM, container, servizio cloud:<\/p>\n

      \n
    • ID univoco (es. `HOST-PROD-001`)<\/li>\n
    • Proprietario (persona o team)<\/li>\n
    • Criticit\u00e0 (C1=mission-critical, C2=business, C3=support)<\/li>\n
    • Dati sensibili? (s\u00ec\/no, se s\u00ec: tipo GDPR\/PCI\/health)<\/li>\n
    • Dipendenze verso altri asset<\/li>\n
    • \u00daltima patch\/aggiornamento config<\/li>\n
    • Compliance attestato? (s\u00ec\/data audit)<\/li>\n<\/ul>\n

      Fase 2: Continuous Discovery & Change Tracking<\/h3>\n

      Ho integrato il mio Plesk control panel con script bash che ogni 4 ore esportano la lista dei container, VPS attive e domini. Qualsiasi delta rispetto allo snapshot precedente trigghera un alert. Un ambiente cloud che ha passato un check di compliance 6 mesi fa potrebbe non passare oggi. Il continuous monitoring per configuration drift, nuove tecniche di attacco e vulnerabilit\u00e0 emergenti \u00e8 essenziale. NIS2 premia le organizzazioni che possono dimostrare una vigilanza continua, non solo sforzo periodico<\/cite>.<\/p>\n

      Ho scritto uno script Bash (potete adattarlo):<\/p>\n

      #!\/bin\/bash
      \n# NIS2 Asset Discovery & Change Tracking
      \nINVENTORY_FILE=\"\/opt\/nis2\/asset_inventory.json\"
      \nLOG_FILE=\"\/opt\/nis2\/asset_changes.log\"
      \nTIMESTAMP=$(date +\"%Y-%m-%d %H:%M:%S\")<\/p>\n

      # Export active VPS from Plesk
      \nplesk db query \"SELECT id, name, status, ip_address FROM domains\" | jq '.' > \/tmp\/current_domains.json<\/p>\n

      # Compare with previous state
      \nif diff -q \/tmp\/current_domains.json $INVENTORY_FILE > \/dev\/null 2>&1; then
      \n echo \"[${TIMESTAMP}] No changes detected\" >> $LOG_FILE
      \nelse
      \n echo \"[${TIMESTAMP}] CHANGE DETECTED - Asset inventory drift\" >> $LOG_FILE
      \n diff \/tmp\/current_domains.json $INVENTORY_FILE >> $LOG_FILE
      \n # Alert SOC team
      \n mail -s \"NIS2: Asset Change Alert\" soc@provider.eu < $LOG_FILE
      \nfi<\/p>\n

      cp \/tmp\/current_domains.json $INVENTORY_FILE
      \n<\/code><\/p>\n

      Questo \u00e8 minimalista ma effettivo\u2014ogni drift viene loggato e l’SOC pu\u00f2 investigare prima che diventi un problema.<\/p>\n

      Architetture Cloud Resiliente: Beyond High Availability<\/h2>\n

      NIS2 non parla di “99.9% uptime”\u2014parla di provable recovery<\/strong>. NIS2 esplicitamente richiede che le organizzazioni implementino misure di continuit\u00e0 robuste\u2014incluse backup management, disaster recovery e crisis-response capabilities\u2014per assicurare che le entit\u00e0 essenziali e importanti possano mantenere le operazioni durante incident disruptive<\/cite>.<\/p>\n

      Ho riprogettato la mia infrastruttura attorno a 3 pilastri:<\/p>\n

      1. Multi-Region Active-Active (dove critico)<\/h3>\n

      L’infrastruttura cloud ti permette di usare multiple regioni geograficamente separate; avere multiple zone configurate dentro una regione assicura l’operazione ininterrotta della regione anche se una zona (un intero datacenter) va persa. Puoi implementare architetture che rendono le soluzioni resilient alla perdita di un’intera regione\u2014il contingency plan pu\u00f2 affrontare il bisogno di un ambiente disaster recovery di produzione<\/cite>.<\/p>\n

      Per i clienti mission-critical (healthcare, fintech), ho distribuito i carichi su EU-West (Irlanda) e EU-Central (Francoforte). La replica \u00e8 sincrona per i database critici, asincrona per contenuto statico. RTO (Recovery Time Objective) = 15 minuti; RPO (Recovery Point Objective) = 5 minuti.<\/p>\n

      2. Backup Immutabile & Air-Gapped<\/h3>\n

      Dopo l’attacco ransomware del 2024 (che ho descritto in un articolo precedente), ho implementato backup che sono impossibili da criptare da remoto<\/strong>:<\/p>\n

        \n
      • Backup giornalieri su object storage S3 con versioning enabled<\/li>\n
      • Copia settimanale su storage locale isolato (non raggiungibile dalla rete production)<\/li>\n
      • Retention: 30 giorni online, 365 giorni in cold archive<\/li>\n
      • MFA obbligatorio per delete operations<\/li>\n<\/ul>\n

        Ho testato questi backup ogni mese\u2014e documento la prova. Cloud-native DR trasforma la resilienza su 5 dimensioni: Opex over capex (eliminate idle standby infrastructure); Automation over complexity (replace manual recovery con Infrastructure-as-Code runbooks); Elastic scale over fixed capacity; Global reach over local limits; Continuous testing over occasional drills<\/cite>.<\/p>\n

        3. Incident Response Architecture: From Detection to Reporting<\/h3>\n

        Ho connesso una pipeline SIEM-to-SOAR che automatizza met\u00e0 della investigazione:<\/p>\n

        WAZUH (log aggregation)
        \n \u2193
        \n [Alert Correlation Rules]
        \n \u2193
        \nSOAR (Shuffle\/Cortex XSOAR)
        \n \u2193
        \n[Automated Evidence Collection]
        \n \u2193
        \n[Incident Ticket + Notification]
        \n \u2193
        \nTeam Engagement (se severity=HIGH)
        \n \u2193
        \n[24-hour CSIRT Notification]
        \n<\/code><\/p>\n

        Quando una brutta anomalia viene rilevata (es. credential abuse, data exfiltration pattern), il SOAR automaticamente:<\/p>\n

          \n
        1. Raccoglie i log rilevanti da tutte le fonti<\/li>\n
        2. Estrae gli IoC (indirizzi IP, hash file, domain names)<\/li>\n
        3. Crea un ticket Jira con assessment preliminare<\/li>\n
        4. Mi notifica via Slack (e email se severity=CRITICAL)<\/li>\n<\/ol>\n

          Questo mi ha tagliato il tempo medio di detection-to-escalation da 4 ore a 22 minuti.<\/p>\n

          Supply Chain Security: Auditing Your Vendors<\/h2>\n

          NIS2 enfatizza che le organizzazioni sono solo quanto il loro vendor pi\u00f9 debole, poich\u00e9 i cybercriminali targetano i link deboli per raggiungere entit\u00e0 pi\u00f9 grandi. Le organizzazioni devono assessare tutti i terzi fornitori di prodotti, software, hardware o componenti essenziali per il funzionamento dei sistemi di rete e informazione. Le entit\u00e0 essenziali e importanti devono eseguire approfonditi risk assessment dei vendor, valutando la qualit\u00e0 dei prodotti\/servizi e resilienza, come i vendor mantengono il loro risk management, e includendo clausole specifiche nei contratti riguardanti la notificazione di incident, la conformit\u00e0 agli standard di sicurezza, e la condivisione di rapporti di audit<\/cite>.<\/p>\n

          Ho creato una vendor risk matrix che valuta:<\/p>\n\n\n\n\n\n
          Vendor<\/strong><\/td>\nCriticit\u00e0<\/strong><\/td>\nISO 27001?<\/strong><\/td>\nIncident SLA?<\/strong><\/td>\nUltima Audit<\/strong><\/td>\nRischio<\/strong><\/td>\n<\/tr>\n
          Cloudflare (CDN\/DDoS)<\/td>\nC1<\/td>\nS\u00ec<\/td>\n1 ora<\/td>\nOtt 2025<\/td>\nBasso<\/td>\n<\/tr>\n
          AWS (Compute)<\/td>\nC1<\/td>\nS\u00ec<\/td>\nContratto SLA<\/td>\nOtt 2025<\/td>\nBasso<\/td>\n<\/tr>\n
          Vendor A (TBD)<\/td>\nC2<\/td>\nNo<\/td>\nNo formale<\/td>\nMai<\/td>\nAlto<\/td>\n<\/tr>\n<\/table>\n

          I vendor ad alto rischio vengono riauditati prima di ogni rinnovo contrattuale. Article 21(2)(d) crea obblighi diretti per third-party risk: le entit\u00e0 devono assessare la postura di cybersecurity dei fornitori diretti, la qualit\u00e0 e resilienza dei loro prodotti e servizi, e la sicurezza delle pratiche di sviluppo dei fornitori. In pratica, questo significa estendere i programmi di third-party risk management per includere clausole contrattuali equivalenti a NIS2, obblighi di notificazione incident dei fornitori che permettono all’entit\u00e0 di incontrare la sua finestra 24-ore, e continuous monitoring dei fornitori ICT critici<\/cite>.<\/p>\n

          Governance Board-Level: Accountability Non \u00e8 Opzionale<\/h2>\n

          NIS2 mette il board in gioco. La gestione deve approvare le politiche, supervisionare i budget, e dimostrare competenza in cybersecurity. Una role map pratica: Board di Direttori \u2192 oversight strategico e risk appetite; CISO\/Compliance Lead \u2192 implementazione giornaliera e reporting; IT Operations \u2192 deployment e monitoraggio dei controlli; Legal Counsel \u2192 liaison normativa e contratti<\/cite>.<\/p>\n

          Ho iniziato a portare un “cybersecurity risk report” mensile al nostro board. Include:<\/p>\n

            \n
          • Vulnerabilit\u00e0 critiche non ancora patchate (e timeline remediation)<\/li>\n
          • Incident detection trend (numero, severity, MTTD\/MTTR)<\/li>\n
          • Vendor audit status<\/li>\n
          • Test di incident response (tabletop o simulazione)<\/li>\n
          • Compliance attestation stato<\/li>\n<\/ul>\n

            Article 20 tiene le management bodies di entit\u00e0 essenziali e importanti direttamente responsabili per approvare e supervisionare le misure di risk management di cybersecurity. Gli stati membri possono imporre responsabilit\u00e0 personale\u2014incluse band temporanee da funzioni di management per executives di entit\u00e0 essenziali<\/cite>. Nel mio caso, c’\u00e8 una firma esplicita da parte del mio AD sul documento di approvazione della cybersecurity policy.<\/p>\n

            Checklist Operativa: 30 Giorni a NIS2 Baseline<\/h2>\n

            Se non sapete da dove partire, ecco il roadmap che ho usato:<\/p>\n

            Settimana 1: Assessment & Scoping<\/h3>\n
              \n
            • \u2610 Confermare che la vostra organizzazione \u00e8 in-scope (>50 dipendenti? >\u20ac10M fatturato? Hosting\/cloud? S\u00ec = siete essenziali)<\/li>\n
            • \u2610 Creare un asset inventory di tutti<\/strong> i sistemi in produzione<\/li>\n
            • \u2610 Classif i 5-10 sistemi pi\u00f9 critici per RTO\/RPO<\/li>\n
            • \u2610 Elencare i vendor terzi\u2014chi ha accesso a dati sensibili?<\/li>\n<\/ul>\n

              Settimana 2: Incident Response Planning<\/h3>\n
                \n
              • \u2610 Definire “significativo” incident secondo NIS2 (severity matrix con criteri chiari)<\/li>\n
              • \u2610 Compilare template 24-hour early warning & 72-hour notification<\/li>\n
              • \u2610 Identificare il contatto CSIRT nel vostro paese<\/li>\n
              • \u2610 Creare una contact list escalation (Security, IT, Legal, Management)<\/li>\n
              • \u2610 Fare un tabletop exercise (simulazione di incident)<\/li>\n<\/ul>\n

                Settimana 3: Technical Hardening<\/h3>\n
                  \n
                • \u2610 Implementare SIEM (Wazuh, Splunk, o equivalente)<\/li>\n
                • \u2610 Enable MFA su tutti gli account administrator<\/li>\n
                • \u2610 Implementare backup immutabile (S3 versioning + air-gap)<\/li>\n
                • \u2610 Network segmentation: isolate production, staging, development<\/li>\n
                • \u2610 Patch tutti i sistemi >30 giorni di lag<\/li>\n<\/ul>\n

                  Settimana 4: Governance & Documentation<\/h3>\n
                    \n
                  • \u2610 Documentare tutte le policy di cybersecurity (risk mgmt, incident response, supply chain)<\/li>\n
                  • \u2610 Eseguire cyber training per staff (ENISA guidelines)<\/li>\n
                  • \u2610 Audit vendor compliance\u2014chiedere ISO 27001 certs & SLA incident<\/li>\n
                  • \u2610 Board presentation: cybersecurity governance approval<\/li>\n
                  • \u2610 Set up audit trail: log tutte le modifiche a sistema critico per 12 mesi<\/li>\n<\/ul>\n

                    FAQ<\/h2>\n

                    NIS2 si applica al nostro piccolo provider hosting in Italia?<\/h3>\n

                    NIS2 classifica provider cloud, hosting, datacenter, CDN, e DNS provider come entit\u00e0 essenziali, il tier di rischio pi\u00f9 alto, soggetto a supervisione proattiva. La soglia di dimensione \u00e8 generalmente 50+ dipendenti o \u20ac10M+ di fatturato. I provider DNS e i TLD registry sono in-scope indipendentemente dalla dimensione<\/cite>. Se fornite hosting o cloud in EU, siete in-scope automaticamente<\/strong>.<\/p>\n

                    Qual \u00e8 la differenza tra “early warning 24-ore” e “notificazione 72-ore”?<\/h3>\n

                    L’early warning a 24-ore \u00e8 inteso solo per allertare le autorit\u00e0. L’analisi tecnica profonda \u00e8 riservata ai report 72-ore e 1-mese<\/cite>. Il 24-ore \u00e8 “veloce e grezzo”\u2014sospettate malware? S\u00ec\/no. Cross-border? S\u00ec\/no. \u00c8 il 72-ore dove dovete fornire IoC, severity assessment, e sistemi colpiti.<\/p>\n

                    Posso delegare NIS2 compliance al mio cloud provider?<\/h3>\n

                    Se un fornitore, MSP, o cloud provider subisce un incident che impatta le vostre operazioni regolate, l’obbligo NIS2 (e la timeline) rimane con voi stessi<\/cite>. Potete mitigare<\/em> il rischio audittando i loro controlli, ma la responsabilit\u00e0 finale \u00e8 vostra. Se AWS ha un breach, voi dovete comunque reportare al vostro CSIRT.<\/p>\n

                    Cosa succede se mancate la deadline di 24-ore?<\/h3>\n

                    Le entit\u00e0 essenziali potrebbero essere multat fino a \u20ac10 milioni o 2% del fatturato globale, a seconda di quale sia pi\u00f9 alto. Le entit\u00e0 importanti potrebbero essere multat fino a \u20ac7 milioni o 1.4% del fatturato globale. A parte le penalit\u00e0 finanziarie, gli organismi di supervisione nazionale possono ordinare audit di sicurezza obbligatori, misure correttive, e la senior management pu\u00f2 essere ritenuta personalmente responsabile per negligenza e pu\u00f2 essere bandita dalle posizioni di gestione<\/cite>. Non \u00e8 una multa da \u20ac5000\u2014\u00e8 una minaccia alla continuit\u00e0 aziendale.<\/p>\n

                    Come faccio a “provare” che sono NIS2-compliant ai regolatori?<\/h3>\n

                    Mantenete un “regulatory pack” per ogni servizio in-scope che includa diagrammi di architettura, flussi dati, liste di fornitori, playbook di incident response, e prova di testing. Questo rende pi\u00f9 facile dimostrare la conformit\u00e0 durante audit o inchieste normative<\/cite>. Nel mio caso, mantengo una dashboard audit-ready che mostra: ultime patch applicate, risultati dei tabletop exercise, evidenza di inventory updates, vendor audit status, e incident response logs.<\/p>\n

                    Conclusione: NIS2 \u00e8 un’Operazione, Non una Checklist<\/h2>\n

                    NIS2 non valuta se un piano esiste. NIS2 valuta se un’organizzazione pu\u00f2 consegnare un early warning coordinato, basato sui fatti, alle autorit\u00e0 entro 24 ore\u2014mentre l’incident \u00e8 ancora in corso. Non \u00e8 un problema di documentazione. \u00c8 un problema di sistema operativo<\/cite>.<\/p>\n

                    Nei miei 10 anni di hosting management, la transizione verso NIS2 \u00e8 stata la pi\u00f9 disruptive. Non \u00e8 solo su “pi\u00f9 sicurezza”\u2014\u00e8 su provability in tempo reale<\/strong>. I regolatori non leggono il vostro documento di cybersecurity policy di 50 pagine. Leggono i vostri log di incident, gli IoC che avete estratto in 48 ore, e se riuscite a dimostrare che i vostri backup sono realmente recuperabili.<\/p>\n

                    Se siete un hosting provider e non avete ancora iniziato, la finestra di opportunit\u00e0 si sta chiudendo. Se avete domande sulla vostra implementazione specifica NIS2 (Plesk, cPanel, Kubernetes, multi-cloud), lasciate un commento\u2014sar\u00f2 felice di aiutare.<\/p>\n","protected":false},"excerpt":{"rendered":"

                    Come implementare NIS2 Compliance per provider hosting: incident reporting 24-72 ore, continuous asset management, architetture cloud resilient e checklist operativa testata.<\/p>\n","protected":false},"author":1,"featured_media":2064,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"NIS2 Hosting Provider: Incident Reporting 24-72h e Asset Management","_seopress_titles_desc":"Guida pratica NIS2 per provider hosting: incident reporting 24-72 ore, asset inventory continuo, resilienza cloud e checklist operativa. Compliance 2026 testata.","_seopress_robots_index":"","footnotes":""},"categories":[3],"tags":[835,791,603,834,631,316],"class_list":["post-2063","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hosting","tag-asset-management","tag-cloud-security","tag-compliance","tag-hosting-provider","tag-incident-response","tag-nis2"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2063","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=2063"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2063\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/2064"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=2063"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=2063"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=2063"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}