Eje 6: Plantillas

Plantilla de catálogo OSCAL

Borrador

El GCBoK define taxonomías de cumplimiento alemanas como catálogos OSCAL, una novedad en el mercado:

oscal_catalog:
  groups:
    - id: "gobdControls"
      title: "GoBD - Nachvollziehbarkeit"
      controls:
        - id: "GOBD-01"
          title: "Progressive Navigation"
          description: "Jeden Geschäftsvorfall rückwärts verfolgbar"
    - id: "bsiControls"
      title: "BSI IT-Grundschutz Module"
      controls:
        - id: "APP.3.1.A1"
          title: "Datensicherung"
    - id: "dsgvoControls"
      title: "DSGVO Anförderungen"
      controls:
        - id: "DSGVO-Art.17"
          title: "Recht auf Vergessenwerden"

Plantilla de política OPA

Borrador

Ejemplo de una política Rego para la validación de comprobantes:

package gitcover.compliance

deny[msg] {
    input.class == "INVOICE"
    not input.prev_sha256
    msg := "INVOICE muss prev-hash referenzieren"
}

deny[msg] {
    input.class == "PAYMENT"
    not input.gpg_fingerprint
    msg := "PAYMENT muss GPG-signiert sein"
}

allow {
    count(deny) == 0
}

Esquema V7GUID

Borrador

El esquema canónico de metadatos V7GUID:

{
  "v7guid": "0197a3b2-f3c0-7b00-8001-000000000042",
  "class": "INVOICE",
  "sha256": "7d4e2f...",
  "prev_sha256": "3f2a1c...",
  "gpg_fingerprint": "ABCD1234...",
  "timestamp_iso": "2026-06-14T11:18:00+02:00",
  "gobd_periode": "FY2026"
}

class es uno de PERSON | INVOICE | PAYMENT | CONTRACT | ...; prev_sha256 es null para el comprobante génesis.

Profundidad de cumplimiento → Estratificación del esquema V7GUID

Según la profundidad de integración del repositorio Git y el nivel de exigencia de cumplimiento, se necesitan diferentes esquemas JSON V7GUID. El GCBoK define una estratificación de esquemas (modelo por niveles) que está vinculada a VariantId, kind y status:

Nivel	Exigencia de cumplimiento	Campos de esquema requeridos	`VariantId`	`kind`	`status`
T1	GoBD/AO únicamente (mínimo)	`v7guid`, `class`, `sha256`, `prev_sha256`, `gpg_fingerprint`, `timestamp_iso`, `gobd_periode`	`10` (conservación durante 10 años §147 AO)	`INVOICE`, `RECEIPT`, `CONTRACT`	`ACTIVE`
T2	PII / RGPD	T1 + `tenant_id`, `org_unit_id`, `data_category` (Art. 9 DSGVO), `retention_legal_basis`	`11` (nivel de protección del RGPD)	`PERSON`, `HR_DATA`	`ACTIVE`
T3	NIS2 (infraestructuras críticas)	T2 + `risk_level`, `incident_reporting_obligation`, `supply_chain_tier`	`12` (clase de riesgo NIS2)	`INFRASTRUCTURE`, `LOG_DATA`	`ACTIVE`
T4	ISO 27001 (completo)	T3 + `control_id` (Anexo A de ISO 27001), `asset_classification`, `treatment_plan_ref`	`13` (IFRS/HGB + ISO)	`POLICY`, `AUDIT_EVIDENCE`	`ACTIVE`

Principio: “Al final solo quedan repositorios Git” — el fallback en comprobaciones/auditorías son artefactos de código + registros/diccionarios .gitcover en formato JSON/JSONL. El paquete HTML de verificación es solo presentación; la forense es el repositorio Git (véase Procedimientos: preparación para auditorías y el derivado gcbok-audit-evidence-docs/docs/02-audit-website-als-pruefungsartefakt).

Los archivos de esquema están versionados en .gitcover/schemas/ del repositorio TOP y se hacen resolubles mediante others.json.

Plantilla de contenedor DMS

El contenedor .gc.zip para GCDMS (alcance según el caso de uso):

document.gc.zip
├── document.gc.md   # Metadaten (SHA-256 des Ur-Dokuments, docUid, v7guid, Taxonomie)
├── document.gc.sig  # GPG-Signatur des Manifests
├── document.pdf     # Originaldokument (Urdokument)
├── document.json    # Maschinenlesbare Extrakte
├── document.xml     # Maschinenlesbare Extrakte (z.B. X-Rechnung)
└── attachments/     # Anhänge

Orden en el contenedor: El manifiesto (document.gc.md) ocupa el primer lugar y lleva el SHA-256 del documento original; las entradas siguen de forma determinista (manifiesto, firma, documento original, extractos, adjuntos). Así, el contenedor es legible sin registro y al mismo tiempo permanece vinculado al object_id del DMS (= docUid del sidecar).

Selección de formato según el caso de uso

Formato	Uso
`.gc.json`	Legible por máquina, políticas OPA, exportación OSCAL
`.gc.md`	Hipervínculos, legible para humanos, interfaz web de Git
`.gc.yaml`	Archivo de configuración, editable por humanos

Plantilla de sidecar de GitCover

Sidecar canónico (*.gc.md) para un documento original digital. Esquema: https://gitcover.org/schemas/v7g-sidecar-2.0.schema.json; los metadatos de la instancia siguen record-metadata-1.0.schema.json (ISO 15489).

DocID = uuidv7 (identificador de instancia) frente a v7guid (identificador de clase/contexto). Ambos se incluyen en el sidecar y se enlazan mediante composite_key ({v7guid}:{uuidv7}). Contenido mínimo: sha256 del documento original.

# GitCover Sidecar - {original_filename}

**SHA-256:** `{sha256}`
**Tenant:** {tenant}
**Kategorie:** {category}
**Sphäre:** {sphere}
**Tags:** {tags}

```json
{
  "$schema": "https://gitcover.org/schemas/v7g-sidecar-2.0.schema.json",
  "docUid": "{uuidv7}",
  "sha256": "{sha256}",
  "title": "{original_filename}",
  "original_filename": "{original_filename}",
  "locations": [
    { "unc_path": "./{tenant}/{path}", "from": "{YYMMDD}", "to": null, "note": "Primärspeicherort" }
  ],
  "v7g_taxonomy": [
    { "v7guid": "{v7guid}", "taxonomy": "{tenant}/{taxonomy}", "valid_from": "{YYMMDD}", "valid_to": null }
  ],
  "gcpn": { "prima_nota_ref": null, "journal_entry_ref": null },
  "obsolescence": { "status": "active", "superseded_by": null, "last_checked_at": "{ts}", "last_checked_by": "{user}" },
  "verification": { "verified_at": "{ts}", "verified_by": "auto", "method": "sha256_file", "intact": true },
  "tags": ["{tag}"],
  "sphere": "{sphere}"
}
```

Asignación de DocID: Cuando el documento se incorpora de nuevo al DMS, la herramienta de sidecar genera un UUIDv7 a partir de un argumento TimeStamp como DocID (uuidV7). La fuente predeterminada es la mtime del archivo; si el nombre del archivo o el contenido proporciona una fecha de negocio, se utiliza esta (véase Eje 5: Procedimientos).