Eje 6: Plantillas

Plantilla de catálogo OSCAL

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

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

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

El esquema canónico de metadatos V7GUID:

v7guid: "0197a3b2-f3c0-7b00-8001-000000000042"
class: INVOICE          # PERSON | INVOICE | PAYMENT | CONTRACT | ...
sha256: "7d4e2f..."
prev_sha256: "3f2a1c..."  # null für Genesis-Beleg
gpg_fingerprint: "ABCD1234..."
timestamp_iso: "2026-06-14T11:18:00+02:00"
gobd_periode: "FY2026"

Profundidad de cumplimiento → Jerarquización del esquema V7GUID

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

Nivel Requisito de cumplimiento Campos de esquema requeridos VariantId kind status
T1 Solo GoBD/AO (mínimo) v7guid, class, sha256, prev_sha256, gpg_fingerprint, timestamp_iso, gobd_periode 10 (conservación de 10 años §147 AO) INVOICE, RECEIPT, CONTRACT ACTIVE
T2 PII / DSGVO T1 + tenant_id, org_unit_id, data_category (Art. 9 DSGVO), retention_legal_basis 11 (nivel de protección DSGVO) 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 (ISO 27001 Anexo A), asset_classification, treatment_plan_ref 13 (IFRS/HGB + ISO) POLICY, AUDIT_EVIDENCE ACTIVE

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

Los archivos de esquema se almacenan con control de versiones en .gitcover/schemas/ del repositorio principal y se hacen resolubles a través de others.json.

Plantilla de contenedor DMS

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

document.v7g.zip
├── .v7g.md          # Metadaten, ggfs. mit Strukturinformationen in Markdown Artefakten (JSON/YAML/XML, SHA256 Hash des Urdokuments, etc.)
├── .v7g.sig         # GPG-Signatur
├── document.pdf     # Originaldokument (Urdokument)
├── document.json    # Maschinenlesbare Extrakte
├── document.xml     # Maschinenlesbare Extrakte (z.B. X-Rechnung)
└── attachments/     # Anhänge

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

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

Plantilla de sidecar V7GUID

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

DocID = uuidv7 (identificador de instancia) vs. v7guid (identificador de clase/contexto). Ambos se gestionan en el sidecar y se vinculan a través de composite_key ({v7guid}:{uuidv7}). Contenido mínimo: sha256 del documento original.

# V7G Sidecar - {original_filename}

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

```json
{
  "$schema": "https://gitcover.org/schemas/v7g-sidecar-1.0.schema.json",
  "uuidV7": "{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 por primera vez al DMS, la herramienta de sidecar genera una UUIDv7 a partir de un argumento de marca de tiempo 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).