WordPress Vedlikehold & Support i Roma

WordPress-vedlikehold i Roma handler sjelden om å bygge noe nytt. Det handler om å holde et nettsted som allerede tar imot bookinger, viser museer og kulturtilbud, eller publiserer offentlig informasjon oppe, raskt og i tråd med EU-regelverk, måned etter måned, mens sesongtopper, språkkrav og krav fra offentlig sektor endrer seg rundt det. Denne siden beskriver hvordan løpende drift og støtte ser ut for en virksomhet i Italias hovedstad som betjener både det lokale og internasjonale markedet med servere og data i EU.

Utgangspunktet er alltid det eksisterende nettstedet, ikke et idealisert ett. Plugin-inventaret, hosting hos Aruba, Register.it, SiteGround EU eller en annen leverandør med datasenter innenfor EØS, backup-historikken, Nexi- eller Stripe-koblingen og IT/EN-strukturen kartlegges først, deretter låses en månedlig rytme som tåler både rolige uker i august og topper når påske, sommerferie og julemarked fyller kalenderen.

#WordPress-vedlikehold og støtte i Roma

Et nettsted i Roma møter en sammensetning av krav som speiler byens rolle som politisk sentrum, turistmagnet og administrativt knutepunkt. Italiensk og engelsk innhold for lokale og internasjonale besøkende, WooCommerce eller bookingsystemer med Nexi eller Stripe som betalingsgateway, skjemaer som samler personopplysninger fra turister og borgere, og over det hele GDPR håndhevet av Garante per la protezione dei dati personali med krav om at personopplysninger behandles lovlig og at brudd varsles innen 72 timer. Vedlikeholdsarbeidet handler om å holde alle disse delene i drift når WordPress-kjernen, betalingspluginene og oversettelsesverktøyene oppdateres ut av takt med hverandre.

#Hva som inngår i den løpende driften

• Oppetidsovervåking med korte kontrollintervaller og varsling til en skriftlig kanal, slik at en nede bookingmotor, et kontaktskjema eller en offentlig informasjonsside oppdages før gjestene eller innbyggerne rapporterer det
• Testede oppdateringer av WordPress-kjerne, plugins og temaer i et testmiljø før produksjon, med dokumentert tilbakeføring per syklus, fordi en Nexi- eller Stripe-oppdatering som bryter betalingscallback koster omsetning og tillit i høysesong
• Daglige sikkerhetskopier med 30 dagers oppbevaring og prøvd gjenoppretting, lagret utenfor produksjonsserveren med tanke på EU-datalagring og leverandørens faktiske datasenterlokasjon
• Sikkerhetsovervåking: malware-skanning, filintegritetskontroll, overvåking av innloggingsforsøk og en Web Application Firewall tilpasset WordPress-spesifikke angrepsmønstre, med referanse til CSIRT Italia og ACN ved bekreftede hendelser
• Kontroll av flerspråklig oppsett etter oppdateringer: hreflang for italiensk og engelsk, språkbytte, oversatte URL-er og metadata, slik at engelske landingssider for turister ikke indekseres feil når redaktøren publiserer en italiensk variant
• Kapasitetsforberedelse før kjente topper: cache, PHP-grenser og køhåndtering sjekkes før påske, sommerferie og julemarked, ikke midt i trafikken
• Noen utviklertimer i måneden satt av til mindre endringer, kampanjesider, sesongoppdateringer og småfeil uten at det må settes opp et eget prosjekt

#Markedet og det tekniske miljøet i Roma

Roma er Italias hovedstad og et av Europas mest besøkte reisemål. Turisme og offentlig sektor dominerer etterspørselen etter WordPress-vedlikehold i byen: hoteller og ferieboligforvaltere nær sentrum og Vatikanet, reisebyråer som selger guidede turer og opplevelser, museer og kulturinstitusjoner med billettering og kalender, og offentlige enheter som må publisere informasjon etter AgID-krav og tilgjengelighetsstandarder. WordPress Roma-meetupen samler utviklere og redaktører som jobber med nettsteder i nettopp disse segmentene, og mange av dem har sett hva som skjer når et nettsted bygget raskt under tidspress møter sesongtopper uten testede oppdateringer.

Det praktiske utslaget for vedlikehold er at Roma-baserte virksomheter ofte trenger noen til å ta over driften uten å bygge alt på nytt. Turismeaktører legger vekt på at booking og betaling fungerer når trafikken kommer fra Tyskland, Storbritannia, USA og Norden, ikke bare fra Italia. Offentlige nettsteder og leverandører til PA digitale legger vekt på at oppdateringer ikke introduserer sårbarheter, at tilgjengelighet ikke forfaller, og at personopplysninger fra skjema og innlogging håndteres i tråd med GDPR og Garante-retningslinjer.

Lokale betalingsvaner avgjør hvilke deler av siden som er mest forretningskritiske. Nexi er utbredt for kortbetaling i Italia, Stripe brukes ofte av aktører som selger til internasjonale turister og nord-europeiske markeder, og PayPal er fortsatt et supplement der kunden forventer det. For hoteller, turer og opplevelser er det ofte depositum, delbetaling og webhook fra betalingsleverandør som må overvåkes tettest. Det styrer hva vi sjekker før hver oppdatering: kasseflyt, tilbakekall fra betalingsgateway, valutavisning og ordrebekreftelse, fordi det er der en feil treffer omsetningen direkte.

Roma Startup Hub og miljøet rundt universitetene og coworking-sentrene i byen betyr at mange team allerede har hørt om testmiljø, WP-CLI og sikkerhetsoppdateringer. Problemet er sjelden mangel på teori, men at ingen eier driften når gründeren har flyttet videre, sesongansatt redaktør har sluttet, eller byrået har avsluttet avtalen rett før påskeferien.

#Verktøyene vi drifter med

Overvåking settes opp med oppetidskontroll og PageSpeed-måling, sikkerhetsskanning kjøres med Wordfence eller tilsvarende, og oppdateringer på tvers av flere nettsteder orkestreres fra ett kontrollpanel. Mange Roma-kunder ligger hos italienske hostingleverandører som Aruba eller Register.it, andre hos OVH, SiteGround med EU-datasenter eller Hetzner med eksplisitt datalagring innenfor EØS. Sikkerhetskopier lagres adskilt fra produksjonsserveren med versjonering, slik at en kompromittert server ikke tar med seg backupene. Valgene tilpasses det som allerede er på plass, vi bytter ikke ut en fungerende stack for å standardisere på vår egen.

For nettsteder som må ligge i EU dokumenterer vi hvor produksjon kjører, om CDN avslutter TLS i avtalt sone, og om backup-buckets ikke replikerer til USA uten Standard Contractual Clauses. Det er vanlige svar som tilfredsstiller compliance-spørsmål fra kundens DPO og fra offentlige innkjøpere som selv er underlagt GDPR og nasjonal personvernlovgivning.

#Slik foregår overtakelsen

Overtakelse av et eksisterende nettsted følger en fast rekkefølge som holder risikoen lav:

1. Onboarding-revisjon, en gjennomgang av WordPress-installasjonen: plugin-inventar, hosting, PHP-versjon, backup-status, sikkerhetsposisjon, språkoppsett og en Lighthouse-referanse å måle mot senere.
2. Overvåking og sikkerhetskopier på plass, oppetid, ytelse og sikkerhet settes under overvåking, daglige backups med prøvd gjenoppretting etableres, og et testmiljø klargjøres for oppdateringstesting.
3. Første testede oppdateringssyklus, kjerne, plugins og temaer oppdateres i testmiljø, kasse, booking og kritiske skjemaer testes, og endringene flyttes til produksjon med en tilbakeføringsplan klar.
4. Månedlig rytme, testede oppdateringer, backups, sikkerhetsskann, ytelseskontroller og en månedsrapport med målinger, beslutninger og gjenværende risiko.
5. Hendelsesrespons, ved nedetid eller en bekreftet sikkerhetshendelse utløses SLA-arbeidsflyten: respons, avgrensning, dokumentert tidslinje og rotårsak, oppretting og oppdatert rapport.

#Problemene vi oftest tar over

Henvendelsene fra Roma-bedrifter handler stort sett om de samme tingene:

• En oppdatering brøt Nexi- eller Stripe-tilbakekallet rett før påske eller sommerferie, og ingen oppdaget det før bestillingene stoppet. Når oppdateringer testes i testmiljø mot kasseflyten først, fanges denne typen feil før de når kundene.
• Nettstedet klappet sammen under sesongtoppen fordi caching ikke var konfigurert for plutselig trafikk fra utenlandske turister som booker turer og hotell samtidig. Da justerer vi CDN, objektcache og databaseforespørsler før neste sesong, ikke etter at salgsavdelingen har rapportert tapte bookinger.
• Flerspråklig kaos etter en oppdatering: italiensk innhold vises på engelske URL-er, hreflang peker feil, eller WPML/Polylang slutter å synkronisere oversettelser. Da sjekker vi språkruting og metadata før indekseringen faller i Google og hos turister som søker på engelsk.
• Redaktører overskriver flerspråklige sider eller publiserer halvferdig innhold på feil språk. Redaksjonelle arbeidsflyter med revisjonshistorikk, planlagt publisering og riktige brukerroller fjerner mesteparten av den friksjonen.
• Offentlige nettsteder med utdaterte plugins, utilgjengelige skjemaer eller admin-kontoer fra gamle leverandører som fortsatt har full tilgang. Revisjonen kartlegger dette før den jevne driften begynner.
• En hostingleverandør med ustabil oppetid eller uklart datasenter utenfor EU. Vi overvåker serveren uavhengig av leverandørens egne tall og kan flytte et nettsted når infrastrukturen svikter gjentatte ganger, med migrasjonsplan som respekterer EU-krav til dataoverføring.
• En side som har stått uten oppdateringer lenge og nå har sårbare plugins, malware eller en backup som ikke virker. Da starter vi med en opprettingsliste før den jevne driften begynner, og ved alvorlige hendelser koordineres varsling i tråd med GDPR og Garante-retningslinjer.

#Hva du kan vente deg

Resultatet av løpende, testet vedlikehold er udramatisk, og det er poenget. Færre supporthenvendelser fordi feil fanges i testmiljø i stedet for i produksjon. Stødigere lastetider når caching, bildeoptimalisering og databaseopprydding er på plass og holdes ved like gjennom sesongtopper og kampanjer. Kortere nedetid ved hendelser fordi backupene faktisk lar seg gjenopprette og responsrutinen er øvd inn. Vi måler før og etter og legger tallene i månedsrapporten i stedet for å love en bestemt prosent på forhånd.

#Hvorfor Roma-bedrifter velger WPPoland

Vi har drevet med WordPress siden 2007 og har sett plattformen gå fra bloggverktøy til forretningskritisk infrastruktur for nettbutikker, bookingløsninger og flerspråklige portaler. Vi vet hva som ryker når et nettsted skaleres under turistsesongen eller når et offentlig nettsted må være oppe mens en informasjonskampanje pågår, og hva en kunde faktisk trenger sammenlignet med det de tror de trenger.

Vi er ikke et hostingselskap som selger vedlikehold som tillegg. Vi er utviklere som drifter nettsteder, både de vi har bygget selv og de andre har bygget. Du snakker direkte med personen som gjør arbeidet, ikke med et ledd imellom, og kommunikasjonen kan foregå på norsk selv om nettstedet betjener det italienske og engelske markedet.

#Sikkerhet og samsvar i en italiensk og EU-kontekst

Sikkerhet i drift handler mer om disiplin enn om enkeltgrep. Herdet serveroppsett, WAF-regler tilpasset WordPress, parametriserte databasespørringer mot SQL-injeksjon, output-escaping mot cross-site scripting og hastighetsbegrensning på innlogging er grunnlinjen. Det som gjør det forretningskritisk i Roma, er at et nettsted som behandler kundedata er underlagt GDPR, håndhevet av Garante per la protezione dei dati personali i Italia og av Datatilsynet for norske behandlingsansvarlige med kunder i EØS.

Ved bekreftede sikkerhetshendelser er CSIRT Italia og ACN nyttige referansepunkter for veiledning om varsling og teknisk håndtering, men de erstatter ikke virksomhetens eget ansvar for å dokumentere hva som skjedde, hvem som ble berørt og hvilke tiltak som ble iverksatt. Garante krever varsling innen 72 timer når et brudd medfører risiko for personers rettigheter, i tråd med personvernforordningen artikkel 33. Et vedlikeholdsoppdrag som ignorerer dette etterlater en juridisk risiko, ikke bare en teknisk.

Datalagring i EU er ofte et eksplisitt krav for nordiske kunder som selger til italienske aktører og for lokale selskaper som behandler turist- og borgerdata. Vi kartlegger hvor databasen, backupene og e-postloggene faktisk ligger, om CDN-en speiler innhold utenfor EØS, og om tredjepartsplugins sender data til USA uten gyldig overføringsgrunnlag. Tilgjengelighet er også relevant: offentlige nettsteder i Italia skal følge AgID-krav og EN 301 549, og en oppdatering som introduserer et utilgjengelig skjema er ikke bare en designsvakhet, den kan utløse klager og tilsyn. Derfor inngår en tilgjengelighetskontroll i oppdateringssyklusen, ikke som et engangsprosjekt.

For nettsteder i offentlig sektor og turisme er tilgangskontroll og logging særlig viktig. Skjemaer som samler navn, reisedatoer, identitetsdokumentreferanser og betalingsdata forventer at dataene ikke er offentlig tilgjengelige og at innloggingssoner oppdateres når sårbarheter oppdages. Vi holder plugin-inventaret stramt, fjerner ubrukte admin-kontoer og dokumenterer endringer slik at en revisjon kan etterprøves uten at noen må gjette hva som ble gjort sist uke.

#Flerspråklig IT/EN-drift

Roma er internasjonal i praksis. Hoteller, reisebyråer, museer og offentlige enheter publiserer ofte på italiensk og engelsk parallelt for å nå både lokale innbyggere og turister fra resten av Europa og verden. Vedlikehold av et flerspråklig WordPress-nettsted handler om mer enn oversettelser:

• Språkruting, at /it/ og /en/ (eller tilsvarende struktur) peker til riktig innhold uten duplikat-URL-er som konkurrerer i søk
• Hreflang, korrekte tagger mellom språkversjoner slik at Google forstår hvilken side som er ment for hvilket marked
• Metadata per språk, titler, beskrivelser og Open Graph-felt som ikke blir blandet mellom WPML, Polylang eller TranslatePress etter oppdatering
• Redaksjonelt eierskap, hvem godkjenner engelsk tekst når italiensk versjon endres, og hvordan revisjonshistorikk fungerer på tvers av språk
• QA før lansering, at engelske landingssider og italienske kontaktskjemaer begge fungerer etter plugin-oppdatering

En oppdatering som bryter språkbytteren eller viser italiensk innhold på engelsk side er en typisk feil vi fanger i testmiljø, spesielt før sesonglanseringer og kampanjer rettet mot internasjonale turister.

#Ytelse som forretningssignal

Lastetid betyr noe i et marked der turister booker hotell og turer på mobil fra et treigt hotellnettverk eller mens de står i kø ved Colosseum. En treg bookingmotor eller et treigt billetteringsskjema mister salg og leads på samme måte som en nede kasse gjør det. Hosting i EU hjelper latens mot italienske og nord-europeiske kunder, men løser ikke et tungt tema med mange aktive plugins på hver side.

Påske, sommerferie og julemarked er de mest forutsigbare trafikktoppene i Roma. Nettsteder som selger opplevelser, hotell og kulturprodukter trenger cache, PHP-grenser og køhåndtering testet før toppen, ikke under den. Ytelsesarbeidet i driften dekker:

• Ressurser, bilder levert som responsive WebP og AVIF, CSS renset og delt per rute, JavaScript redusert og lastet etter behov
• Caching, flere lag: nettlesercache, CDN, applikasjonscache og databasecache med fornuftig invalidering, slik at en cachelagring ikke serverer utdatert pris, feil tilgjengelighet i bookingkalenderen eller gammel sesonginformasjon
• Nettverk, HTTP/3, Brotli-komprimering og ressurshint der det faktisk flytter målingen fra et italiensk eller nordisk målepunkt
• Rendering, kritisk CSS innlinjet, ikke-kritiske stilark lastet asynkront, og lazy loading av bilder under folden uten å ødelegge LCP på produktsider og gallerier

Hver endring måles mot en referanse fra onboardingen, slik at effekten er etterprøvbar i månedsrapporten. Før kjente topper og lanseringer kjører vi et eget gjennomgang av cache, PHP-grenser og Action Scheduler-kø, fordi Roma-markedet har lite toleranse for eksperimenter når trafikken kommer.

#Spørsmål Roma-bedrifter stiller

Kan dere overta et nettsted dere ikke har bygget selv? Ja, det er det vanligste tilfellet. Revisjonen kartlegger hva som finnes, og den første måneden går ofte mer til opprydding enn til jevn drift.

Hva skjer hvis en oppdatering bryter kassen eller Nexi/Stripe? Oppdateringer kjøres i testmiljø og testes mot kasse og betaling før produksjon, og hver syklus har en tilbakeføringsplan. Skulle noe likevel slippe gjennom, ruller vi tilbake først og finner årsaken etterpå.

Håndterer dere nettsteder på italiensk og engelsk? Ja. Vi sjekker språkruting, hreflang, oversatte metadata og at oppdateringer ikke ødelegger WPML, Polylang eller tilsvarende uten at noen merker det før indekseringen faller.

Må hosting ligge i Italia? Ikke alltid, men data må som regel forbli i EU med avtalt dokumentasjon under GDPR. Vi kartlegger produksjon, backup og CDN i onboarding og flagger avvik før de blir et compliance-spørsmål mot Garante eller kundens DPO.

Hvordan forbereder dere nettstedet før turistsesongen? Vi legger kjente datoer i en årlig kalender og kjører kapasitets- og cachegjennomgang i god tid før toppen. Det inkluderer test av checkout, webhook og CDN-invalidering der det er mulig.

Jobber dere bare med bedrifter i Roma? Vi har kunder i hele Italia og i Norden som betjener EU-markeder. Driften er uansett ekstern, med rapportering og SLA avtalt skriftlig.

Hvordan faktureres løpende vedlikehold? Vedlikehold faktureres månedlig etter en avtalt pakke. Omfang og pris settes individuelt etter antall nettsteder, integrasjoner og responskrav, og avtales før arbeidet starter.

Hvordan foregår kommunikasjonen? Via en skriftlig billettkanal med en månedlig statusrapport. Telefon brukes når en beslutning må avblokkeres eller en hendelse skal gjennomgås.

#Teknisk omfang

Denne siden holder seg til WordPress-vedlikehold og støtte. Arbeidet tar utgangspunkt i tjenesten i tittelen: gjennomgang av nåsituasjonen, et risikokart, prioriterte tiltak, akseptkriterier og verifisering etter hver endring for en virksomhet i Roma. Dukker en annen plattform eller et annet system opp underveis, behandles det som kontekst for driften, ikke som en grunn til å bytte tema.

#Sikkerhetskopier og gjenoppretting som er testet

En sikkerhetskopi uten testet gjenoppretting er en antakelse, ikke en beredskap. Den vanligste svakheten vi finner i revisjonsfasen i Roma er ikke at backup mangler. Det er at backupen kjører, rapporterer grønt og aldri har blitt rullet tilbake til et fungerende nettsted. Et arkiv kan være ubrukelig på måter loggen ikke fanger opp: databasedumpen ble tatt uten --single-transaction mens en booking ble skrevet, tegnsettet ble eksportert feil slik at italienske tegn som è og à kommer tilbake ødelagt, wp-content/uploads ble hoppet over fordi katalogen passerte en størrelsesgrense hos hostingleverandøren, eller arkivet ligger på samme disk som den serveren du nettopp mistet. Forskjellen mellom en sikkerhetskopi og et gjenopprettingspunkt er én konkret handling: at noen har lagt arkivet inn i et rent miljø og bekreftet at nettstedet kommer opp, at innlogging virker, at kassen tar imot en testbestilling og at bildene faktisk vises.

3-2-1-prinsippet er minstekravet, ikke en ambisjon. Tre kopier av dataene, lagret på to ulike medier eller lagringstyper, og minst én kopi utenfor lokasjonen til produksjonsserveren. For et WordPress-nettsted i drift betyr det i praksis den daglige kopien hos hostingleverandøren, en uavhengig kopi i objektlagring hos en annen leverandør innenfor EU, og en versjonert kopi med lengre oppbevaring som produksjonsmiljøet ikke har skriverettigheter til. Begrunnelsen for den tredje kopien er ikke diskhavari, det er løsepengevirus og utilsiktet sletting. Et angrep som får skrivetilgang på serveren rammer også de sikkerhetskopiene serveren selv kan skrive til. Derfor skal minst én kopi være uforanderlig eller ligge bak påloggingsinformasjon som verken webserveren eller WordPress-installasjonen har.

Et komplett øyeblikksbilde består av fire deler, og de tas sjelden samtidig. En backuprutine som bare dekker to av dem gir en falsk trygghet som først viser seg under press:

• Filene. Hele installasjonen, inkludert wp-content/plugins, wp-content/themes, wp-content/mu-plugins og egen kode som ligger utenfor wp-content. Kjernefilene kan hentes tilbake fra WordPress selv, men et spesialtilpasset tema eller en integrasjon skrevet for kunden finnes bare i arkivet ditt.
• Databasen. En konsistent dump laget med wp db export eller mysqldump med --single-transaction og riktig tegnsett, slik at bestillinger som skrives mens eksporten pågår ikke havner halvveis i filen. Serialiserte verdier i wp_options og wp_postmeta er grunnen til at en domene- eller URL-endring etter gjenoppretting må gjøres med wp search-replace, aldri med søk og erstatt i SQL-filen.
• Opplastingene. wp-content/uploads er nesten alltid den største delen og den som først utelates for å holde arkivet lite. Mediebiblioteket kan sikkerhetskopieres med et annet intervall enn databasen, men det skal være en dokumentert beslutning i vedlikeholdsavtalen.
• Serverkonfigurasjonen. wp-config.php med nøkler og salt, .htaccess eller nginx-konfigurasjonen, PHP-innstillinger, cron-oppsettet, sertifikater, DNS-oppføringer og hvilke API-nøkler som peker mot Nexi, Stripe, booking eller fraktleverandører. Denne delen mangler i de fleste plugin-baserte backupløsninger.

Hvor ofte gjenopprettingen bør testes. En gjenopprettingstest er en øvelse, ikke en kontroll av at filen finnes. Vi anbefaler en full gjenoppretting til et rent testmiljø hvert kvartal, og i tillegg etter hver strukturelle endring: bytte av hostingleverandør, migrering, ny PHP-versjon, ny betalingsintegrasjon eller en større WooCommerce-oppgradering. Mellom kvartalstestene holder det med en lettere kontroll der arkivet pakkes ut, databasedumpen importeres, og fem punkter sjekkes: forsiden, innlogging til wp-admin, en produktside eller bookingflyt, en testbestilling gjennom kassen og et bilde fra mediebiblioteket. Prosedyren skal være skrevet ned og kunne følges av en annen person enn den som satte opp backupen.

RPO og RTO, forklart i klartekst. RPO, Recovery Point Objective, svarer på hvor mye data virksomheten tåler å miste, målt i tid. Kjører backupen én gang i døgnet, er RPO i verste fall et helt døgn. RTO, Recovery Time Objective, svarer på hvor lenge nettstedet kan være nede før tapet ikke lenger er akseptabelt, og den klokken inkluderer alt: å finne ut hva som skjedde, hente arkivet ned, importere databasen, teste, endre DNS og varme opp cachen. For en nettbutikk eller bookingplattform i Roma som tar bestillinger gjennom turistsesongen betyr et RPO på ett døgn at bestillinger i verste fall bare eksisterer hos betalingsleverandøren og må avstemmes manuelt etterpå. De konkrete verdiene settes i vedlikeholdsavtalen.

Den første timen etter et datatap. Rekkefølgen betyr mer enn hastigheten:

1. Stopp skrivingen. Sett nettstedet i vedlikeholdsmodus og deaktiver planlagte importer og synkroniseringsjobber.
2. Bevar bevisene før du rydder. Ta en kopi av dagens tilstand, både filsystem, database og logger. Ved mistanke om innbrudd er den kompromitterte tilstanden grunnlaget for å finne inngangspunktet.
3. Fastslå tidspunktet, ikke symptomet. Finn siste kjente gode tilstand ved hjelp av logger, bestillingsnumre og publiseringstidspunkter.
4. Velg den siste verifiserte kopien før det tidspunktet. Ikke den nyeste hvis den kan være kompromittert.
5. Gjenopprett til et separat miljø først. Verifiser kasse, skjemaer, bilder og integrasjoner mot Nexi, Stripe og bookingflyt. Først når miljøet er godkjent, settes det i produksjon.
6. Avstem tidsrommet du mistet. Hent data fra betalingsleverandør, CRM og e-postarkiv.
7. Bytt alle passord og nøkler hvis kompromittering ikke kan utelukkes. Databasepassord, SSH-tilgang, API-nøkler og salter i wp-config.php.
8. Skriv tidslinjen mens den er fersk. Ved personopplysningsbrudd kan GDPR artikkel 33 kreve varsling til Garante innen 72 timer etter at bruddet ble oppdaget.

Responstider og eskaleringsvei følger av vedlikeholdsavtalen og settes sammen med RPO og RTO. Det som avgjør utfallet er arbeidet som ble gjort før hendelsen: at kopien var komplett, at den lå utenfor rekkevidde for det som gikk galt, og at noen hadde gjenopprettet den minst én gang mens det ikke hastet.

For nettbutikker er inngangen WooCommerce-utvikler i Roma. Huber i andre italienske byer sammenligner SLA med vedlikehold i Milano, vedlikehold i Bologna og vedlikehold i Firenze.

#Vedlikehold i andre italienske byer

Trenger du løpende WordPress-vedlikehold utenfor Roma, er oppgavene de samme - oppdateringer, sikkerhetskopier, overvåking og støtte - men med lokal kontekst for drift og responstid. Se også vedlikehold og support i Milano, vedlikehold og support i Bologna og vedlikehold og support i Torino for hvordan avtalen tilpasses der.

#Start en samtale

Hvis virksomheten din i Roma trenger noen til å overta drift og støtte av et WordPress-nettsted, ta kontakt for en uforpliktende gjennomgang. Vi ser på dagens situasjon, peker på den mest presserende risikoen og gir en ærlig vurdering av hva som bør gjøres først. Pris og omfang avtales individuelt etter den gjennomgangen.