La lliçó anterior va acabar assenyalant el que apareixia una vegada i una altra en aplicar el RGPD: RAT, contractes, registre de bretxes, informes de restauració, documents datats abans de l'incident. El Reglament en diu responsabilitat proactiva, NIS2 en diu avaluació de l'eficàcia, ISO 27001 en diu informació documentada i el client en diu «envia'm l'informe». Tots demanen el mateix: no n'hi ha prou d'estar segur, cal poder demostrar-ho. Aquesta lliçó construeix el sistema que ho fa possible sense que costi tres dies de pànic cada vegada: què fa vàlida una evidència, com es recull sola, com es completa la matriu de traçabilitat que arrosseguem des de 04-03, com es comporta un auditor de debò i què pregunta quan demana una mostra, i com es respon a una troballa sense discutir ni exagerar.

Contingut

  1. Estar segur i poder demostrar-ho són coses diferents
  2. Què és una evidència i què la fa vàlida
  3. La matriu de traçabilitat, en la seva forma final
  4. Automatitzar la recollida d'evidències
  5. Tipus d'auditoria: qui la fa i què s'hi juga
  6. El procés d'una auditoria, pas a pas
  7. Com es comporta un auditor i què pregunta de debò
  8. Troballes i pla d'accions correctives
  9. L'auditoria interna en una empresa de 38 persones
  10. Auditoria tècnica davant d'auditoria de gestió
  11. Els qüestionaris de clients com a auditoria de facto
  12. Mètriques de compliment i les dues trampes

  1. Estar segur i poder demostrar-ho són coses diferents

Dues organitzacions poden tenir exactament el mateix nivell de protecció real i resultats oposats davant d'un client, un auditor o l'AEPD. La diferència no és la seguretat: és el rastre.

Demostra poc Demostra bé
És segura El cas més freqüent en pimes tècniques. Protegida de debò, perd contractes, suspèn auditories i en un expedient no pot acreditar diligència L'objectiu. La seguretat existeix i deixa rastre
No és segura El punt de partida honest: hi ha feina per endavant i se sap El pitjor cas de tots: teatre de compliment. Certificat vàlid i bretxa real

D'aquest quadre en surten les dues afirmacions que estructuren la lliçó, i convé sostenir-les totes dues alhora perquè cadascuna corregeix l'excés de l'altra. El compliment sense seguretat és teatre: un certificat ISO 27001 sobre controls que ningú no verifica no va impedir cap de les bretxes de 02-06, i Equifax tenia programa de compliment amb el pedaç sense aplicar. La seguretat sense evidència no sobreviu: ni a una auditoria, ni a un qüestionari de client, ni a un canvi de responsable, ni a un expedient on la ponderació valora expressament la diligència; i tampoc no sobreviu a si mateixa, perquè sense registre ningú no sap si el control continua funcionant, que és la tesi de 06-01. Hi ha a més un argument de cost que sol convèncer qui veu el compliment com a burocràcia: l'evidència és més barata si es genera en fer la feina que si es reconstrueix després. Guardar la sortida de la prova de restauració costa zero minuts el dia que es fa la prova, i costa mitja jornada tres mesos després, quan cal recordar qui la va fer, buscar al xat i redactar un informe a posteriori que a més val menys perquè no és contemporani. L'auditoria no és cara: reconstruir és car.


  1. Què és una evidència i què la fa vàlida

Una evidència és qualsevol registre que permeti a un tercer raonable concloure que un control existeix i funciona: no és una afirmació, no és una captura solta i no és «ho fem sempre». Cinc atributs, i si en falten dos ja no és evidència:

Atribut Què significa Com es trenca
Atribuïble; datada; íntegra Se sap qui la va generar i quan, i no ha estat alterada des de llavors Un PDF sense autor; una captura sense rellotge ni metadades; un .docx editable en carpeta compartida
Reproduïble; conservada Una altra persona, amb el mateix procediment, obtindria el mateix; i sobreviu el temps exigit «Ho vaig mirar i estava bé»; el correu de l'empleat que va marxar; el xat purgat als 90 dies

Tipus d'evidència i exemples presos de tot el curs, complint la promesa de 05-07: el mòdul 5 no només va millorar la seguretat de Nimbus, va anar generant exactament el material que ara fa falta.

Tipus Què demostra Exemple real a Nimbus Origen
Document aprovat; configuració exportada; registre del sistema Que existeix una decisió i qui la va prendre; l'estat real d'un sistema en una data; que alguna cosa va passar i qui la va fer POL-02 i POL-04 amb acta i versió; política del bucket A-02 amb bloqueig públic; taula d'auditoria append-only (C-07) 04-02, 05-02, 05-06
Informe d'eina / de tercer Comprovació automatitzada; verificació independent Sortida de trivy, prowler, lynis, pip-audit, checkov; fitxa PT-2026-01 i el seu retest 05-01, 05-03
Resultat de prova Que el control funciona, no que existeix Informe de restauració amb RTO mesurat; captura de l'alerta D-04 en provar-la 04-06, 05-02
Acta; tiquet tancat; accessos revisats Que hi va haver revisió i decisió; que un procés es va seguir sencer; recertificació efectiva Acta mensual signada de C-21; alta d'usuari amb aprovador i perfil; matriu semestral de C-18 02-05, 04-03

Dos criteris per no equivocar-se en triar. Prefereix sempre l'evidència que la màquina genera sola —una exportació, un registre, la sortida d'un escàner— davant de la que escriu una persona: la primera és reproduïble i difícil de maquillar. I el que separa els bons dels mediocres: l'evidència més valuosa és la que demostra que el control va detectar alguna cosa i es va corregir. Un informe de restauració impecable trimestre rere trimestre resulta sospitós; un que diu «va funcionar, però no recreava els rols nimbus_api i nimbus_informes, corregit el 25/06 i reverificat» demostra que la prova va ser real.


  1. La matriu de traçabilitat, en la seva forma final

A 04-03 la vam esbossar com a eina de gestió de controls; aquí assoleix la seva forma definitiva, amb les dues columnes que faltaven —evidència i freqüència— i amb el mapatge a requisits de 06-02. És un sol document que respon a cinc preguntes: quin risc cobreixo, quina regla ho exigeix, què faig, com ho demostro i qui en respon.

Risc Requisit Política Control Evidència Resp. Freq. Últ. verif.
R-01 Ransomware per tercer RGPD 32.1.b · NIS2 21.2.j · ISO A (identitats) POL-02 5.2.1 C-01 MFA FIDO2 Informe mensual de l'SSO: privilegiats amb i sense MFA Lucía Mensual 2026-07-01
R-01 NIS2 21.2.d · ISO A (proveïdors) POL-08 6.2 C-03 Just-in-time 8 h (A-19) Registre de sessions + sol·licituds autoritzades Lucía Trim. 2026-09-30
R-02 Destrucció de còpies RGPD 32.1.c · NIS2 21.2.c POL-09 5.4 C-14 Còpies immutables provades Informe de restauració amb RTO mesurat i hash Lucía Trim. 2026-06-18
R-04 Fuita d'adjunts RGPD 32.1.b · ISO A (desenvolupament) POL-07 C-05/C-06 RLS + URL signades Proves d'autorització del CI + consulta SQL d'auditoria Iván Cada release 2026-07-22
R-05 Frau BEC RGPD 32.4 · CIS 9.x POL-04 C-13 SPF/DKIM/DMARC p=reject Informe DMARC agregat + captura de la zona DNS Lucía Mensual 2026-07-01
R-06 Secrets / R-08 Portàtil ISO A (desenvolupament) · RGPD 32.1.a POL-07, POL-06 C-12 gitleaks · C-11 Xifratge de disc Sortida del CI i històric de bloqueigs; informe de l'MDM Iván, Lucía Cont./mens. 2026-07-22
R-09 Persona única ISO A (organitzatius) POL-01 C-17/C-21 Runbooks + revisió mensual Runbooks versionats + acta signada Marta Mensual 2026-07-03
Tots RGPD 32.1.d · NIS2 21.2.f POL-01 Verificació anual independent Informe PT-2026-01 + informe de retest Marta Anual 2026-09-20

I la seva versió com a dada, que permet generar informes, detectar caducitats i alimentar el quadre de comandament sense feina manual:

# tracabilitat.yml — una entrada per control. Viu al repo, es revisa en PR.
- control: C-14
  nom: "Copies 3-2-1-1-0 amb copia immutable en compte separat"
  riscos: [R-02, R-01]
  requisits: ["RGPD 32.1.c", "NIS2 21.2.c", "ISO 27001 A (copies)", "CIS 11.2/11.3"]
  politica: "POL-09 5.4"
  responsable: Lucia
  estat: Implantat
  verificacio: {metode: "Restauracio completa a entorn aillat amb
                 verificacio d'integritat", frequencia_dies: 90,
                 ultima: 2026-06-18,
                 resultat: "COMPLEIX — RTO mesurat 3h12m sobre objectiu de 4h"}
  evidencia: {id: EV-C14-2026Q2, tipus: "Informe de prova", retencio_mesos: 24,
              ubicacio: "evidencies/2026/Q2/EV-C14-2026Q2.pdf", sha256: "e3b0..."}
  troballes_obertes: []          # AC-2026-011 tancada el 2026-06-25

Per què mantenir-la al dia és més barat que reconstruir-la, amb un càlcul que la Marta pot portar a una reunió: mantenir-la costa uns 10 minuts per control i trimestre —anotar la data, enllaçar l'evidència, tancar la troballa—, unes 15 hores l'any per a 22 controls; reconstruir-la davant d'una auditoria o un client urgent costa 40-60 hores de la Marta i la Lucía en tres dies, amb material incomplet perquè hi ha evidència que ja no existeix: el registre va rotar, el xat es va purgar, la persona va marxar. I el que es reconstrueix a posteriori val menys davant d'un auditor precisament per no ser contemporani. La matriu al dia costa un terç i val el doble. Un detall d'implantació que canvia el resultat: viu al repositori, no en un full de càlcul a l'escriptori de ningú, amb control de versions, revisió en pull request i un script setmanal que avisa dels controls la ultima verificació dels quals ha superat la seva frequencia_dies.


  1. Automatitzar la recollida d'evidències

La regla que fa sostenible tot l'anterior: si una evidència s'ha de recordar, no es generarà. Bona part es pot extreure sola:

Evidència És automatitzable? Com
Cobertura d'MFA; xifratge del parc; configuració de buckets i xarxa API del proveïdor d'identitat i de l'MDM o consulta osquery; prowler o terraform show
Vulnerabilitats, dependències, proves d'autorització i línia base Informes de trivy i pip-audit, sortida del CI per release, lynis setmanal i ansible --check --diff
Accessos revisats; prova de restauració Parcial L'exportació i l'execució són automàtiques; la revisió, la signatura i la validació, no
Acta de revisió per la direcció; aprovació d'una política No Decisions humanes: s'automatitza el recordatori, mai l'acta

La frontera és nítida i convé respectar-la: s'automatitza el que és un fet verificable; no s'automatitza el que és un judici o una decisió. Fingir el contrari produeix actes generades per un script que cap auditor no accepta i que, pitjor, fan que ningú no revisi res. Un recol·lector que segella el que recull:

#!/usr/bin/env bash
# recollir-evidencies.sh — dia 1 de cada mes, des del CI.
set -euo pipefail
PERIODE="$(date +%Y-%m)"; DEST="evidencies/${PERIODE}"; mkdir -p "$DEST"
sso-cli users list --privileged --format json > "$DEST/C-01_mfa.json"     # C-01
nmap -sT -Pn -oX "$DEST/C-10_escaneig.xml" "$OBJECTIU_EXTERN" >/dev/null  # C-10
terraform -chdir=infra show -json > "$DEST/C-04_infra.json"               # C-04
mdm-cli devices --fields hostname,encrypted,recovery_key_escrowed --format csv \
    > "$DEST/C-11_xifratge.csv"                                           # C-11
trivy image --format json "$IMATGE_PROD" > "$DEST/C-16_trivy.json"        # C-16
pip-audit --format json > "$DEST/C-16_pip_audit.json"                     # C-16
psql "$DB_URL" -f consultes/auditoria.sql --csv > "$DEST/C-07_audit.csv"  # C-07

( cd "$DEST" && sha256sum ./* > MANIFEST.sha256 )     # INTEGRITAT
date -u +"%Y-%m-%dT%H:%M:%SZ" > "$DEST/RECOLLIT_EL.txt"
cosign sign-blob --key "$COSIGN_KEY" --output-signature "$DEST/MANIFEST.sig" \
    "$DEST/MANIFEST.sha256"                           # ATRIBUCIO (03-06)
aws s3 sync "$DEST" "s3://nimbus-evidencias/${PERIODE}/" \
    --only-show-errors                                # CONSERVACIO (05-07)

echo "[+] Periode ${PERIODE}: recollit, segellat i emmagatzemat"
echo "[!] PENDENT D'ACCIO HUMANA: acta de C-21 (Marta) i tancament d'alertes"

Tres decisions de disseny fan que això valgui com a evidència i no com un munt de fitxers. El manifest de hashos dona integritat: qualsevol pot comprovar que el fitxer no ha canviat. La signatura dona atribució no repudiable, amb la mateixa infraestructura de 03-06 i 05-07. I l'emmagatzematge immutable amb Object Lock impedeix que algú —un atacant esborrant petjades, o algú amb pressa abans d'una auditoria— alteri l'històric. Fixa't a més que l'script acaba dient el que no pot fer: és la millor manera que la part humana no s'oblidi. L'efecte sobre l'auditoria és el que importa: quan l'auditor demana «l'evidència del control de xifratge dels últims dotze mesos», la resposta no és una cerca de tres dies, és un directori amb dotze carpetes datades, signades i verificables.


  1. Tipus d'auditoria: qui la fa i què s'hi juga

Tipus Qui la fa Què busca Què s'hi juga Freqüència a Nimbus
Autoavaluació Un mateix L'estat real abans que ningú Res de formal; la més barata i útil Semestral
Interna Algú de la casa que no executa el que s'audita Conformitat amb les polítiques pròpies i el marc triat Credibilitat interna; exigida per ISO 27001 (9.2) Anual
De client El client o un tercer contractat per ell Que el proveïdor compleix el pactat El contracte A demanda, 1-3 l'any
De certificació; reguladora Entitat acreditada; autoritat (AEPD, NIS2) Conformitat amb la norma; compliment legal El certificat; sanció o ordre de cessament Fase 1+2 i seguiment anual; només si hi ha reclamació

Tres observacions de gestió que estalvien disgustos. L'autoavaluació és la de més retorn i la que gairebé ningú no fa: descobrir un buit un mateix costa corregir-lo; descobrir-lo un auditor costa corregir-lo i explicar per què no ho sabies. L'auditoria de client és la més freqüent i la pitjor preparada: arriba amb dues setmanes d'avís, la fa algú que no coneix la teva arquitectura i s'hi juga la renovació, així que es prepara abans, amb el dossier de l'apartat 11. I la reguladora no es prepara: s'hi arriba preparat, perquè quan l'AEPD escriu el marge és de dies i només serveix el que ja existia i estava datat.


  1. El procés d'una auditoria, pas a pas

flowchart TD
    A["1. PLA I ABAST\nQuins sistemes, periode i marc.\nQue s'EXCLOU i per que.\nAcordat per escrit"] --> B["2. REUNIO INICIAL\nCalendari, interlocutors,\nlogistica. Aqui es fixa el to"]
    B --> C["3. REVISIO DOCUMENTAL\nPolitiques, SoA, matriu,\nriscos, contractes"]
    C --> D["4. ENTREVISTES\nA qui EXECUTA, no nomes a qui\nmana. Contrast amb l'escrit"]
    D --> E["5. PROVES I MOSTREIG\nEs demana una mostra i se segueix\nel rastre. El nucli de tot"]
    E --> F["6. TROBALLES + 7. TANCAMENT\nPreliminars, contrastades amb\nl'auditat. La reunio de tancament es el\nmoment d'aportar evidencia, no de discutir"]
    F --> H["8. INFORME\nTroballes classificades, abast,\nmetode, mostres i conclusio"]
    H --> I["9. PLA D'ACCIO\nCausa arrel, propietari, termini i\nVERIFICACIO D'EFICACIA"]
    I -. "seguiment" .-> A

Dos punts decideixen el resultat. L'abast (pas 1) és la decisió més important i la menys discutida: defineix què s'audita i, sobretot, què queda fora. Massa estret, l'informe no serveix al client que el va demanar; massa ampli, dispara el cost i garanteix troballes irrellevants. Nimbus hauria de demanar abast sobre la plataforma SaaS de producció i els processos que la sostenen, excloent per escrit el que no toca dades de client. I el mostreig (pas 5) és on es veu si el sistema és real: l'auditor no revisa els 22 controls amb la mateixa profunditat, en tria uns quants i els persegueix fins al final. Per això un sistema que funciona suporta qualsevol mostra, i un de maquillat es trenca amb la segona pregunta.


  1. Com es comporta un auditor i què pregunta de debò

El malentès més gran sobre les auditories és creure que consisteixen a revisar documents. Un auditor competent fa el contrari: pren una afirmació escrita, demana una mostra concreta i segueix el rastre fins al final, buscant el punt on el paper i la realitat divergeixen. Dues entrevistes simulades, amb el que l'auditor comprova a cada pregunta.

7.1 Entrevista a la Lucía (sistemes)

AUDITOR: POL-02 exigeix MFA resistent al phishing en accessos privilegiats.
         Ensenyi'm les cinc últimes altes administratives i la seva aprovació.
LUCIA:   [Filtra el gestor de tiquets per "Alta - perfil sistemes": cinc
         tiquets amb sol·licitant, aprovador, perfil i data d'execució.]
   -> Comprova: el procés existeix, deixa rastre i és CONSULTABLE en viu. Si
      s'hagués de buscar al xat, la troballa ja estaria escrita.

AUDITOR: I com sé que TOTS els privilegiats tenen MFA, no aquests cinc?
LUCIA:   Informe mensual del proveïdor d'identitat: vuit privilegiats, vuit
         amb MFA. Dotze mesos d'històric, amb manifest de hashos signat.
   -> Comprova: POBLACIO COMPLETA davant de mostra. La diferència entre
      "aquests casos van anar bé" i "el control cobreix l'univers".

AUDITOR: A l'informe de febrer hi veig 7 de 8. Què va passar?
LUCIA:   Una alta del dia 27 sense MFA fins al 2 de març: incidència AC-2026-004,
         causa —alta fora del flux per urgència— i correcció: l'SSO ja no
         permet una alta sense segon factor.
   -> Comprova: EL MILLOR QUE POT PASSAR EN UNA AUDITORIA. Fallada detectada pel
      mateix sistema, amb causa arrel i correcció verificada. NO és una
      troballa: és la prova que el control funciona.

AUDITOR: La seva política diu 7 dies per aplicar pedaços al que és crític.
         Doni'm l'últim mes.
LUCIA:   Quatre crítiques: tres en 2, 3 i 5 dies. La quarta, 11 dies, a
         l'heretat A-22, registrada com a excepció amb justificació, caducitat
         i compensació: A-22 aïllat i sense dades de client.
   -> Comprova: HONESTEDAT DAVANT LA DESVIACIO. Dir "sempre en 7 dies" i que
      l'auditor trobi el d'11 val infinitament menys.

7.2 Entrevista a l'Iván (desenvolupament)

AUDITOR: Com garanteixen que un client no veu les dades d'un altre?
IVAN:    Tres capes: autorització centralitzada amb tenant_actual, que impedeix
         que l'identificador arribi com a paràmetre; RLS a PostgreSQL com a
         xarxa de seguretat; i proves d'autorització al CI.
AUDITOR: Ensenyi'm la prova que fallaria si algú ho trenqués.
IVAN:    [El test crea dos tenants, autentica com a A, demana un recurs de B i
         espera 404. Mostra la seva execució a l'últim pipeline.]
AUDITOR: Esborri'l i faci'l passar: vull veure el CI en vermell.
IVAN:    [Comenta la comprovació de tenant; el pipeline falla.]
   -> Comprova: l'afirmació té un artefacte EXECUTABLE al darrere i el control
      és EFECTIU. "Ho revisem al code review" és una afirmació; un test que
      es pot trencar davant de l'auditor és evidència.

AUDITOR: PT-2026-01 va reportar un IDOR en informes. Com sé que està tancat?
IVAN:    Informe de retest amb la troballa verificada, el commit que l'arregla
         i un test de regressió que reprodueix el cas exacte de l'informe.
   -> Comprova: TANCAMENT DEL CICLE. Una troballa sense retest no està tancada.

AUDITOR: Qui pot desplegar a producció? I si el pipeline és caigut?
IVAN:    Ningú a mà: només el pipeline sobre la branca principal, amb revisió
         aprovada i CODEOWNERS que exigeix segon revisor en autenticació i
         autorització. Per a la urgència hi ha procediment documentat: l'executa
         la Lucía, l'aprova la Marta i genera revisió posterior. S'ha fet servir
         dues vegades aquest any; aquí les té.
   -> Comprova: EL CAMI ALTERNATIU. Els controls no se salten pel camí
      principal sinó per la porta del darrere: l'auditor pregunta sempre per
      l'excepció.

El que aquestes dues entrevistes ensenyen és transferible a qualsevol auditoria: l'auditor no busca perfecció, busca coherència entre l'escrit, el que la gent diu i el que el sistema mostra; la incoherència és la troballa. I una organització que reconeix les seves desviacions amb el seu registre i la seva correcció puntua millor que una altra que afirma no tenir-ne cap i és desmentida pel seu propi registre.


  1. Troballes i pla d'accions correctives

Tipus de troballa Què significa Conseqüència Exemple a Nimbus
No-conformitat major Absència total d'un requisit, o fallada sistèmica Bloqueja la certificació fins a corregir i verificar No existeix anàlisi de riscos; no s'ha fet auditoria interna; el control d'accessos no cobreix un sistema de l'abast
No-conformitat menor Fallada puntual que no compromet el sistema Pla d'acció amb termini; no bloqueja Dues de dotze actes sense signar; una excepció sense caducitat
Observació / millora Risc latent o tendència preocupant; o suggeriment de l'auditor Sense obligació formal; convé atendre-la «La dependència d'una sola persona pot afectar la continuïtat del SGSI»

Com es respon a una troballa. Hi ha dues maneres de fer-ho malament i una de fer-ho bé. Discutir —intentar convèncer l'auditor que no és una troballa— perd temps i credibilitat llevat d'error de fet documentable, i de vegades provoca una revisió més profunda. Exagerar —acceptar-ho tot i prometre corregir-ho la setmana vinent— produeix accions sense tancar al seguiment, i una acció correctiva incomplerta és pitjor que la troballa original perquè qüestiona el sistema sencer. El correcte és comprendre exactament la troballa, repetint-la amb les pròpies paraules fins que l'auditor ho confirmi; aportar l'evidència que potser no es va trobar si existeix i està datada; acceptar el que és cert; i comprometre una correcció amb causa arrel, propietari i termini realista.

Plantilla d'acció correctiva:

# AC-2026-023 — Acció correctiva
Origen: auditoria interna 2026 · NC-menor 03 · Oberta 2026-10-14
Propietari: Lucía · Termini: 2026-11-30

1. TROBALLA (literal). «S'han revisat 12 actes mensuals de revisió de
   canvis privilegiats (C-21). Dues (abril i agost) no consten signades ni
   datades, per la qual cosa no es pot acreditar que la revisió es realitzés.»
2. CORRECCIÓ IMMEDIATA. No es firmaran actes retroactives: es documenta
   l'absència i es reforça el control d'ara endavant.
3. CAUSA ARREL (cinc per-quès). No estan signades perquè ningú no va generar
   l'acta; no es va generar perquè era un document manual; era manual perquè el
   control es va definir sense suport en eina; i això va passar perquè es va
   prioritzar definir controls per damunt d'instrumentar-los. **Causa arrel: els
   controls administratius es van dissenyar sense decidir quin artefacte els
   evidenciaria ni qui ho faria.**
4. ACCIÓ CORRECTIVA (la causa, no el símptoma). a) L'acta passa a ser un tiquet
   recurrent amb plantilla, generat el dia 1, responsable Marta: **tancar el
   tiquet ÉS l'acta** —període, anomalies, decisions i data—. b) Alerta si
   continua obert el dia 10. c) Revisar els altres 8 controls administratius
   perquè cadascun tingui artefacte d'evidència (això evita la reincidència).
5. VERIFICACIÓ D'EFICÀCIA — SENSE AIXÒ NO ESTÀ TANCADA. 2027-02-01, tres cicles
   després. Criteri: els tiquets de nov./des./gen. existeixen, tancats en
   termini i amb contingut mínim. Verifica: Marta. Resultat: [pendent].
6. TANCAMENT. EN CURS, fins que el pas 5 doni COMPLEIX.

Els dos elements que distingeixen un pla d'acció real són el 3 i el 5. Sense causa arrel es corregeix el símptoma i la troballa reapareix l'any següent amb un altre nom —signar dues actes endarrerides no hauria canviat res—. I sense verificació d'eficàcia en data futura, l'acció es declara tancada el dia que s'implanta, just quan encara no se sap si funciona. És la lògica de 04-05 i 05-03: sense retest no hi ha tancament.


  1. L'auditoria interna en una empresa de 38 persones

ISO 27001 l'exigeix (clàusula 9.2) i NIS2 empeny en la mateixa direcció, però el seu valor és anterior a qualsevol norma: és l'única manera de saber com s'està abans que ho digui algú de fora. L'obstacle aparent és la independència, i n'hi ha prou amb la mínima viable: qui audita no audita el que executa. Amb cinc persones hi ha combinacions suficients:

Àmbit auditat Qui l'executa Qui l'audita
Control d'accessos i infraestructura Lucía Marta, amb guió preparat
Desenvolupament segur, CI i gestió de proveïdors Iván / Marta Lucía; i un consultor extern per al que la Marta aprova
Tractament de dades i drets; suport i accés a dades de client Sara / Marta; Rubén Consultor extern o el DPD; Iván

Quan no hi ha independència possible —la Marta audita processos que ella mateixa aprova—, la solució honesta és contractar dos dies d'auditor extern l'any (1.500-2.500 €) per a aquesta part i declarar-ho a l'informe: amagar la falta d'independència és una troballa, declarar-la és una limitació d'abast acceptable.

# Programa d'Auditoria Interna 2027 — Nimbus Reservas, S.L.
Aprovat per Marta (CTO) el 2026-12-15 · Marc: ISO 27001 + CIS v8 IG1

1. OBJECTIU I ABAST. Verificar que C-01…C-22 estan implantats, operen amb
   eficàcia i generen l'evidència declarada a la matriu de traçabilitat.
   Abast: plataforma SaaS de producció, desenvolupament i processos de suport.
   Exclusió justificada: gestió laboral (l'audita la gestoria).
2. CRITERIS. POL-01…POL-11 · controls · CIS v8 IG1 · mapa normatiu (06-02).
3. CALENDARI. Feb — accessos i infraestructura (C-01,03,04,11,18), la Marta
   audita la Lucía, 6 h. Maig — desenvolupament i CI (C-05,06,07,12), la Lucía
   a l'Iván, 6 h. Set — proveïdors, contractes i dades (C-22, art. 28), extern
   a la Marta i la Sara, 12 h. Nov — còpies, continuïtat i resposta
   (C-14,17,19), l'Iván a la Lucía, 6 h.
4. MÈTODE. Revisió documental · entrevista a l'executor · **mostreig seguint
   el rastre complet** · prova efectiva del control sempre que es pugui
   (injectar una alerta, restaurar, trencar un test).
5. MOSTREIG I SORTIDES. Mínim 5 elements per control si la població supera 20;
   completa si és menor. **La mostra la tria l'auditor, no l'auditat.**
   Informe per cicle · accions correctives amb causa arrel i verificació
   d'eficàcia · informe anual per a la direcció.

I la plantilla d'informe, deliberadament curta:

# Informe d'Auditoria Interna — Cicle Feb/2027
Àmbit: accessos i infraestructura · Auditor: Marta · Auditat: Lucía
2027-02-09 a 2027-02-11 · 6 h · Controls C-01, C-03, C-04, C-11, C-18
Criteris: POL-02, POL-06, POL-08, CIS v8 (5, 6, 12). Mètode: revisió
documental, entrevista, mostreig de 5 elements i prova efectiva de C-03.
RESUM: 4 conformes · 1 no-conformitat menor · 2 observacions · 0 majors.
| Id | Tipus | Control | Descripció | Acció |
|---|---|---|---|---|
| NC-01 | Menor | C-18 | La recertificació de set. es va executar, però no consta la retirada efectiva de 2 accessos marcats per revocar | AC-2027-002 |
| OB-01 | Observ. | C-03 | El just-in-time funciona, però la revocació depèn d'un únic temporitzador sense alerta de fallada | AC-2027-003 |
| OB-02 | Observ. | C-11 | 1 equip de 41 sense xifratge verificat (alta recent) | Corregit a l'auditoria |

ASPECTES POSITIUS (es documenten: sostenen el programa). C-03 provat en viu:
l'accés es va revocar a les 8 h exactes. Evidències de 12 mesos, signades i
verificables en menys de 2 minuts.
CONCLUSIÓ. El sistema opera amb eficàcia en l'àmbit auditat. NC-01 no
compromet el conjunt, però afecta un risc crític (R-01) i s'ha de tancar
abans del 2027-04-30.
Signat: Marta (auditor) · Rebut: Lucía (auditat) · 2027-02-11

L'apartat d'aspectes positius no és cortesia: un programa d'auditoria que només produeix males notícies deixa de ser benvingut, i llavors la gent comença a preparar la foto en lloc d'ensenyar la realitat.


  1. Auditoria tècnica davant d'auditoria de gestió

Es confonen constantment, i confondre-les porta a creure que s'està cobert quan no s'hi està.

Auditoria tècnica Auditoria de gestió
Pregunta Aquesta configuració és correcta i és explotable? Existeix el procés, se segueix i es demostra?
Objecte i exemples Sistemes, codi i configuració: pentest (05-03), prowler, lynis, revisió de codi Polítiques, processos i decisions: ISO 27001, ENS, auditoria interna, qüestionari de client
Troba / no troba Un bucket obert, un IDOR, TLS obsolet; no veu que la política no existeixi ni que ningú no revisi res Que ningú no revisa accessos des de fa 14 mesos; no veu l'IDOR explotable en producció

Totes dues són necessàries perquè fallen en llocs diferents. El pentest PT-2026-01 va trobar l'IDOR residual, que cap auditoria de gestió no hauria vist; i una auditoria de gestió va trobar que dos accessos marcats per revocar continuaven actius, que cap pentest no hauria mirat. Un sistema pot estar impecablement configurat i no tenir qui el mantingui; i pot tenir un SGSI exemplar sobre una infraestructura vulnerable. Precisió important: el pentest de 05-03 és una evidència, no una auditoria. Acredita el requisit de «verificació regular de l'eficàcia» —article 32.1.d del RGPD, clàusula 9 d'ISO 27001— i per això figura a l'última fila de la matriu de l'apartat 3. Presentar-lo com a auditoria de conformitat és un error que els auditors detecten immediatament i que deixa al descobert el que el pentest no mira: governança, contractes, formació, registres i decisions.


  1. Els qüestionaris de clients com a auditoria de facto

A 06-02 vam veure com respondre'ls amb honestedat; aquí, com industrialitzar-los, perquè són l'auditoria més freqüent que pateix una pime i la que pitjor escala: el primer costa 20 hores i el cinquè hauria de costar 3. El dossier de seguretat reutilitzable, mantingut per la Marta i revisat cada sis mesos:

# dossier-seguretat/index.yml — paquet que es lliura sota NDA a clients
versio: "2026.3"
revisat: 2026-10-01
proper_repas: 2027-04-01
responsable: Marta

public:    # sense NDA: privacitat i avis legal, fitxa de seguretat de 2 pagines,
           # subencarregats i ubicacions (art. 28), security.txt i VDP (06-06)
sota_nda:
  - "Arquitectura i fluxos de dades (sense IPs ni noms de host)"
  - "Matriu de controls C-01..C-22 amb estat i frequencia de verificacio"
  - "Resum executiu del pentest PT-2026-01 + confirmacio de retest"
  - "Ultima prova de restauracio (RTO/RPO mesurats) · resum del BIA"
  - "Informe d'auditoria interna · procediment de notificacio de bretxes"
  - "Contracte d'encarregat del tractament (model)"

mai_es_lliura:
  - "Informe complet de pentest amb reproduccio pas a pas"
  - "Diagrames amb IPs, noms de host o versions exactes"
  - "Configuracions en brut, tallafoc, infraestructura com a codi"
  - "Registres sense depurar (contenen dades d'altres clients)"
  motiu: "Es lliurar un mapa d'atac, i pot vulnerar la
          confidencialitat deguda a altres clients"

faq_respostes_aprovades: "dossier-seguretat/faq.md"   # 90 preguntes tipus

El banc de respostes (faq.md) és el que produeix l'estalvi: cada pregunta respondida un cop, amb la seva redacció aprovada, la seva evidència associada i la seva data de revisió. En arribar un qüestionari nou, el 80 % es respon copiant. Regla de manteniment: cada resposta nova s'incorpora al banc el mateix dia, o l'estalvi no arriba mai. I un consell de negociació que estalvia setmanes: quan un client envia 90 preguntes clarament dissenyades per a un proveïdor d'una altra mida, oferir el dossier per avançat i preguntar què queda sense respondre sol reduir-lo a deu preguntes específiques; és més ràpid per a tots dos i transmet maduresa.


  1. Mètriques de compliment i les dues trampes

L'estat de cada control es classifica en quatre valors, i la definició estricta importa més que la mètrica: implantat (existeix, opera i està verificat dins de la seva freqüència), parcial (existeix però no cobreix tota la població, o la seva verificació està caducada), no implantat (decidit però no operatiu) i no aplicable (justificat per escrit, amb raó de negoci).

#!/usr/bin/env python3
"""Estat de compliment a partir de tracabilitat.yml. S'executa al CI."""
from datetime import date
import yaml

AVUI = date(2026, 11, 1); controls = yaml.safe_load(open("tracabilitat.yml"))
def estat_efectiu(c):
    """Un control verificat fora de termini NO compta com a implantat."""
    if c["estat"] != "Implantat":
        return c["estat"]                           # Parcial/No impl./No aplic.
    ultima, freq = c["verificacio"]["ultima"], c["verificacio"]["frequencia_dies"]
    if ultima is None: return "Parcial"             # mai verificat
    return "Implantat" if (AVUI - ultima).days <= freq else "Parcial"

resum, caducats = {}, []
for c in controls:
    e = estat_efectiu(c)
    resum[e] = resum.get(e, 0) + 1
    if e == "Parcial" and c["estat"] == "Implantat":
        u = c["verificacio"]["ultima"]
        caducats.append((c["control"], (AVUI-u).days if u else None, c["responsable"]))

aplicables = sum(v for k, v in resum.items() if k != "No aplicable")
implantats = resum.get("Implantat", 0); print(f"ESTAT DE COMPLIMENT — {AVUI}\n" + "-" * 60)
for k in ("Implantat", "Parcial", "No implantat", "No aplicable"):
    print(f"  {k:<16}: {resum.get(k, 0):>3}")
print(f"  Cobertura efectiva: {round(100*implantats/aplicables, 1)} % de "
      f"{aplicables} aplicables")
for cid, dies, resp in caducats:
    print(f"  CADUCADA {cid}: {dies} dies -> {resp} (compta PARCIAL)")
ESTAT DE COMPLIMENT — 2026-11-01
------------------------------------------------------------
  Implantat : 17    Parcial : 3    No implantat : 1    No aplicable : 1
  Cobertura efectiva: 81.0 % de 21 aplicables
  CADUCADA C-08: 137 dies -> Lucia (compta PARCIAL)
  CADUCADA C-18: 198 dies -> Marta (compta PARCIAL)

L'important no és el percentatge: és la regla de degradació. Un control verificat fora de la seva freqüència deixa automàticament de comptar com a implantat, sense que ningú ho hagi de decidir, de manera que el número baixa sol quan la feina s'abandona en lloc de quedar-se congelat al 100 % del dia que es va declarar acabada. És la tesi de 06-01 convertida en aritmètica. I les dues trampes que arruïnen un programa de compliment, totes dues subtils perquè semblen productivitat: Auditar només el que és fàcil d'evidenciar. Els controls que produeixen un informe bonic —xifratge, MFA, aplicació de pedaços— s'auditen sempre; els que no —la qualitat de la revisió d'accessos, si algú mira de debò les alertes, si el runbook serveix sota pressió— es donen per bons. El resultat és un quadre en verd amb els riscos pitjor coberts precisament on no hi ha focus. Antídot: incloure a cada cicle almenys un control «difícil» i provar-lo de debò —injectar una alerta i cronometrar la resposta, demanar a algú que executi un runbook sense ajuda—. Optimitzar per a l'auditoria en comptes de per al risc. És la degeneració clàssica: es tria el control que quedarà bé a l'informe, s'ajusta l'abast per excloure el que és problemàtic, es maquilla un termini. Tot és defensable per separat i el conjunt produeix un certificat sobre una empresa que no està protegida. Antídot: mantenir sempre dos indicadors separats i publicats junts —cobertura de compliment (aquest apartat) i risc residual (04-01)—. Quan el primer puja i el segon no baixa, alguna cosa s'està optimitzant per a la foto.


Errors Comuns i Consells

  • Confondre tenir un control amb poder demostrar-lo. Les còpies existeixen, però sense informe de restauració datat no compleixes el 32.1.c ni el 32.1.d i, davant d'un auditor, no existeixen. I no reconstrueixis evidències abans de l'auditoria: costa tres vegades més, surt incompleta, no és contemporània i un auditor experimentat ho detecta per l'homogeneïtat sospitosa dels documents.
  • Evidències en eines efímeres. El xat es purga, el correu se'n va amb la persona, el full de l'escriptori desapareix: l'evidència viu en un repositori amb retenció declarada. Tancar accions el dia que s'implanten i corregir el símptoma. Sense verificació d'eficàcia en data futura l'acció està ajornada, no tancada; i sense causa arrel la troballa torna amb un altre nom. Discutir amb l'auditor llevat d'error documentable perd credibilitat i guanya una revisió més profunda. I no lliuris l'informe complet de pentest a un client: és un mapa d'atac; es lliura el resum executiu i la confirmació de retest, sota confidencialitat.
  • Consell: guarda l'evidència el dia que fas la feina. Costa zero minuts llavors i mitja jornada tres mesos després. És l'única regla d'aquesta lliçó que, aplicada sola, ja la rendibilitza.
  • Consell: audita tu primer, i documenta també el que va funcionar. Descobrir un buit propi costa corregir-lo; descobrir-lo un tercer costa corregir-lo i explicar per què no ho sabies. I un informe que només porta males notícies deixa de ser benvingut: llavors la gent prepara la foto en lloc d'ensenyar la realitat.

Exercicis

Exercici 1 — Convertir afirmacions en evidències

La Marta ha escrit quatre afirmacions per respondre a un client: (1) «tots els nostres empleats reben formació en seguretat»; (2) «revisem periòdicament qui té accés a les dades dels clients»; (3) «les nostres còpies de seguretat són immutables i estan provades»; (4) «detectem accessos anòmals a les dades dels nostres clients». Per a cadascuna, indica quina evidència concreta la sostindria, si és automatitzable o requereix judici humà, amb quina freqüència s'ha de generar i quina pregunta faria un auditor per posar-la a prova.

Exercici 2 — Una troballa i la seva acció correctiva

A l'auditoria interna de setembre, l'auditor extern demana una mostra de sol·licituds d'accés de la consultora (A-19) de l'últim trimestre. Troba onze sessions registrades però només set sol·licituds amb autorització prèvia: les altres quatre es van executar i van quedar registrades, sense rastre de qui les va autoritzar. La Lucía explica que van ser incidències urgents de cap de setmana i que ella les va autoritzar verbalment. Classifica la troballa justificant-ne el tipus, redacta l'acció correctiva completa amb les sis seccions de la plantilla, i explica per què «d'ara endavant la Lucía enviarà un correu de confirmació» seria insuficient.

Exercici 3 — Dissenyar el cicle d'auditoria interna que més dol

Nimbus només pot dedicar 6 hores a un cicle d'auditoria interna, i la Marta vol que sigui el que més informació aporti sobre el risc real, no el que produeixi l'informe més lluït. Tria l'àmbit, digues quins controls auditaries, com provaries cadascun de debò (no revisant documents), quina mostra demanaries i què esperaries trobar. Justifica per què aquest àmbit i no un altre.

Solucions

Exercici 1

Afirmació Evidència concreta És automatitzable? Freqüència Pregunta de l'auditor
1. Formació Registre nominal amb data, contingut i acreditació de realització (no només d'enviament); acceptació signada de POL-04; material versionat Parcial: el registre sí; la qualitat i l'efecte, no Contínua + informe trimestral «Doni'm la llista completa i la seva última formació. I els tres que van entrar al setembre?»
2. Revisió d'accessos Matriu semestral amb llista de partida, decisió per accés, retirades executades i data, signada per la Marta Parcial: l'exportació sí; la decisió i la signatura, no Semestral (C-18) «Ensenyi'm els accessos que es va decidir retirar i demostri'm que ja no existeixen»
3. Còpies Informe de restauració amb RTO mesurat, hash i recompte de files; Object Lock exportat; intent fallit d'esborrament amb AccessDenied Parcial: l'execució i la configuració sí; la validació, no Trimestral (C-14) «Quan va ser l'última restauració i quant va trigar? Ha intentat esborrar una còpia per veure si pot?»
4. Detecció Catàleg D-01…D-12 amb la seva definició; registre de dispars i del seu tancament; i sobretot prova periòdica d'injecció amb captura de l'alerta i la seva marca de temps Sí en la major part: definició, dispars i prova Contínua + prova trimestral «Ensenyi'm l'última vegada que aquesta alerta va saltar i què es va fer. Si no ha saltat mai, com sap que funciona?»

La lliçó transversal: les quatre afirmacions són certes en moltes empreses i cap no és demostrable sense l'artefacte de la segona columna. I en tres de les quatre la pregunta de l'auditor apunta al mateix lloc: no a que el control existeixi, sinó a que s'hagi provat i que la mostra difícil —l'empleat nou, l'accés retirat, l'alerta que mai no va saltar— també estigui coberta. La quarta és la més fràgil: un catàleg de deteccions que mai no ha disparat és indistingible d'un que no funciona.

Exercici 2

Classificació: no-conformitat MENOR, amb argument per considerar-la major. És menor perquè el control existeix, està definit a POL-08 6.2.3, s'aplica en 7 d'11 casos i la resta va quedar registrada, així que no hi ha fallada sistèmica. L'argument per elevar-la és seriós: afecta R-01, el risc pitjor puntuat, i el vector exacte de l'incident de 02-06 va ser l'accés no controlat d'aquesta mateixa consultora; un auditor rigorós podria sostenir que un control que falla el 36 % de les vegades sobre el risc crític no està operatiu. La resposta correcta no és discutir la classificació, sinó tractar-la amb la serietat d'una de major.

# AC-2026-031 — Acció correctiva
Origen: auditoria interna set./2026 · NC-menor 01 · Risc R-01
Oberta 2026-09-30 · Propietària: Marta · Termini: 2026-11-15

1. TROBALLA. «Sobre 11 sessions d'accés del proveïdor extern (A-19) al
   trimestre, 4 es van executar sense sol·licitud ni autorització prèvia
   registrada, incomplint POL-08 6.2.3. Les sessions sí que consten al registre
   tècnic.»
2. CORRECCIÓ IMMEDIATA. Les 4 sessions es contrasten amb les incidències
   d'aquelles dates: intervencions reals i necessàries, sense activitat indeguda.
   La Marta les autoritza a posteriori de manera motivada, **deixant constància
   que és una regularització i no una autorització prèvia**.
3. CAUSA ARREL. Falten perquè van passar en cap de setmana; no es va autoritzar
   perquè el flux exigia un tiquet aprovable només en horari laboral; es va
   saltar perquè **el sistema permetia concedir l'accés sense autorització
   prèvia** —control procedimental, no tècnic—; i era procedimental perquè en
   dissenyar C-03 es va instrumentar el fàcil (caducitat a 8 h) i no el difícil.
   **Causa arrel: no hi ha camí autoritzat per a la urgència i el control no
   està forçat pel sistema, així que la urgència l'evita.**
4. ACCIÓ CORRECTIVA. a) **Autorització tècnicament obligatòria**: A-19 es
   concedeix només pel flux automatitzat, sense via manual. b) **Camí
   d'urgència legítim 24×7**: aprovació des del mòbil per dos aprovadors
   (Marta, Iván suplent), SLA de 15 min; s'elimina la raó per saltar-se'l.
   c) **Trencament de vidre** si cap no respon: accés amb avís immediat a
   tots dos i revisió obligatòria en 24 h, marcat com a excepcional.
   d) **Detecció**: alerta S1 (D-03) davant de sessió d'A-19 sense autorització,
   per saber-ho en minuts i no al cap de nou mesos. e) **Contracte**: cap
   intervenció sense sol·licitud prèvia serà facturable.
5. VERIFICACIÓ D'EFICÀCIA. 2027-01-15, dos trimestres després. Criteri: 100 %
   de sessions amb autorització prèvia registrada, D-03 sense dispars
   injustificats i almenys un ús del camí d'urgència dins de l'SLA (si no
   n'hi hagués, simulacre). Verifica: auditor extern. 6. TANCAMENT. EN CURS.

Per què «la Lucía enviarà un correu de confirmació» és insuficient, i el raonament val per a gairebé qualsevol troballa: (1) no ataca la causa arrel —el problema no és que la Lucía s'oblidi d'escriure, és que no hi ha un camí autoritzat per a la urgència i el sistema permet la drecera—; (2) manté el control com a procedimental, és a dir, dependent de la memòria d'una persona sota pressió un diumenge a la nit, que és just quan la memòria falla (06-01); (3) la Lucía no pot ser qui autoritzi el seu propi accés: això no és autorització, és autoservei, i elimina la separació de funcions que dona sentit al control; (4) no hi afegeix detecció, així que la desviació següent es tornaria a descobrir nou mesos després en una altra auditoria; i (5) no produeix evidència estructurada, sinó un correu solt en una bústia, que és exactament el tipus d'evidència efímera que aquesta lliçó desaconsella. La regla general: si l'acció correctiva depèn que algú se'n recordi, no és una acció correctiva.

Exercici 3

Àmbit triat: detecció i resposta (C-07, C-08, C-09, C-17 i les deteccions D-01…D-12). I la justificació és la que ordena tot l'exercici: és l'àmbit on la distància entre el que està documentat i el que és real és sistemàticament més gran. Les polítiques d'accés o de xifratge són fàcils de verificar i solen estar bé; en canvi, un catàleg de dotze deteccions escrit en un document i un runbook impecable poden conviure perfectament amb la incapacitat de veure un atacant durant vint dies. És exactament el que va passar a 02-06, i l'àmbit que cap qüestionari de client no sap avaluar.

Com provaria cada control de debò, en 6 hores:

Control Prova real (no documental) Temps Què demostra
D-04 Accés massiu al bucket Descarregar 600 objectes de prova d'A-02 i cronometrar fins que sona el mòbil de guàrdia 45 min Que l'alerta existeix, dispara i arriba a un humà: tres fallades possibles, i només una és visible en un document
D-03/D-08 Credencial fora de finestra; registre desactivat Simular una sessió d'A-19 un dissabte; desactivar el registre d'un recurs no crític 1 h El control que va fallar el dia 0 de 02-06; i l'alerta que cap atacant no vol que existeixi
C-07 Auditoria append-only UPDATE i DELETE amb el rol nimbus_api i capturar l'error; verificar la cadena d'integritat 45 min Que «append-only» és real i no una convenció de noms
C-17 / RB-01 Runbook Demanar a l'Iván, que no el va escriure, que executi el runbook de contenció sense ajuda de la Lucía, amb cronòmetre 2 h El que val un runbook de debò: que una altra persona el pugui seguir
MTTD real i tancament Revisar les alertes dels últims 90 dies —quantes es van tancar, en quant de temps, quantes sense comentari— i redactar l'informe 1,5 h Si la revisió diària existeix o és aspiracional

Mostra que demanaria, i el criteri és que la tria l'auditor, no l'auditat: les 10 últimes alertes de qualsevol severitat —no les que la Lucía proposi— seguint cadascuna fins al seu tancament, i totes les S1 del semestre. Què esperaria trobar, sent realista amb una pime: que dues o tres deteccions no s'han provat mai i una no dispara —llindar mal calibrat, canvi de format del registre, credencial del col·lector caducada—, que és la troballa més probable i la més valuosa; que les alertes de severitat baixa es tanquen sense comentari, cosa que impedeix distingir «revisada i descartada» d'«ignorada»; que el runbook té buits de coneixement tàcit —on és una credencial, a qui trucar, quina ordre exacta—, troballa que ataca directament R-09 i que cap revisió documental no hauria produït; i que el MTTD real és pitjor que el declarat, perquè el declarat es calcula sobre els incidents detectats i no sobre els que es van detectar tard. Per què aquest cicle i no un altre. Un cicle sobre polítiques produiria un informe polit amb dues observacions cosmètiques i cap informació nova. Aquest produeix troballes incòmodes sobre el risc crític —la ceguesa que va costar 20 dies a 02-06—, prova controls en lloc de llegir-los, i de passada valida la feina del mòdul 5 en condicions reals. A més té un efecte secundari que per si sol justifica les 6 hores: en acabar, l'Iván sap executar el runbook, amb la qual cosa l'auditoria no només ha mesurat el risc R-09, l'ha reduït.


Conclusió

Has après a separar dues coses que es confonen amb conseqüències cares: estar segur i poder demostrar-ho. Amb les dues afirmacions que cal sostenir alhora —el compliment sense seguretat és teatre i la seguretat sense evidència no sobreviu a una auditoria, a un client, a un canvi de responsable ni a si mateixa— i amb l'argument econòmic que convenç qui veu això com a burocràcia: l'evidència és més barata si es genera en fer la feina que si es reconstrueix després; l'auditoria no és cara, reconstruir és car. Saps què és una evidència i què la fa vàlida: atribuïble, datada, íntegra, reproduïble i conservada, amb la taula de tipus i els seus exemples presos de tot el curs —POL-02 aprovada, la política del bucket A-02 exportada, la taula d'auditoria C-07, les sortides de trivy, prowler i lynis, l'informe de restauració amb RTO mesurat, la fitxa PT-2026-01 i el seu retest, l'acta signada de C-21, el tiquet d'alta tancat, la matriu de recertificació—, complint la promesa de 05-07 que el mòdul 5 anava generant exactament el material que ara fa falta. Amb els dos criteris d'elecció: prefereix l'evidència que la màquina genera sola, i recorda que l'evidència més valuosa és la que demostra que el control va detectar alguna cosa i es va corregir.

Tens la matriu de traçabilitat en la seva forma final, amb risc, requisit, política, control, evidència, responsable, freqüència i última verificació, en taula i com a yaml que viu al repositori i es revisa en pull request; amb el càlcul que la justifica davant la direcció: 15 hores l'any mantenir-la davant de 40-60 reconstruir-la, i amb material incomplet perquè el registre va rotar i la persona va marxar. Saps automatitzar la recollida amb un recol·lector que exporta, segella amb hashos, signa i emmagatzema en emmagatzematge immutable, respectant la frontera correcta —s'automatitza el fet verificable, no el judici— i acabant amb la llista del que només pot fer una persona.

Distingeixes els cinc tipus d'auditoria i què s'hi juga en cadascun, coneixes el procés complet de nou passos amb els dos punts on es decideix el resultat —l'abast i el mostreig—, i sobretot saps com es comporta un auditor de debò: no revisa documents, pren una afirmació, demana una mostra i segueix el rastre, buscant la incoherència entre l'escrit, el que la gent diu i el que el sistema mostra. Les dues entrevistes simulades t'han ensenyat les preguntes que importen —població completa davant de mostra, el camí alternatiu d'emergència, «esborri'l i faci'l passar»— i la lliçó més contraintuïtiva: reconèixer una desviació amb el seu registre i la seva correcció puntua millor que afirmar que no n'hi ha cap.

Saps classificar troballes —major, menor, observació, oportunitat—, respondre sense discutir ni exagerar, i redactar un pla d'accions correctives els dos apartats decisius del qual són l'anàlisi de causa arrel i la verificació d'eficàcia en una data futura: sense el primer la troballa torna amb un altre nom, i sense la segona l'acció es declara tancada just quan encara no se sap si funciona. Saps muntar l'auditoria interna en una empresa de 38 persones amb la independència mínima viable —qui audita no executa— i comprant dos dies d'extern on no n'hi ha, amb el seu programa anual i el seu informe que també documenta el que va funcionar, perquè un programa que només porta males notícies deixa de ser benvingut. Distingeixes l'auditoria tècnica de la de gestió, saps que fallen en llocs diferents i per què el pentest és una evidència, no una auditoria. I saps industrialitzar els qüestionaris de clients amb un dossier de tres nivells —públic, sota confidencialitat i el que mai es lliura, perquè l'informe complet de pentest és un mapa d'atac—. Tanques amb el quadre d'estat per control i la seva regla de degradació automàtica, i amb les dues trampes: auditar només el que és fàcil d'evidenciar i optimitzar per a l'auditoria en comptes de per al risc, l'antídot de les quals és publicar junts compliment i risc residual.

Curs de Fonaments de Seguretat Informàtica

Mòdul 1: Introducció a la Seguretat Informàtica

Mòdul 2: Ciberseguretat

Mòdul 3: Criptografia

Mòdul 4: Gestió de Riscos i Mesures de Protecció

Mòdul 5: Eines i Tècniques de Seguretat

Mòdul 6: Bones Pràctiques i Normatives

Mòdul 7: Projecte Final

© Copyright 2026. Tots els drets reservats