Achse 6: Vorlagen

OSCAL-Katalog-Template

Entwurf

Das GCBoK definiert deutsche Compliance-Taxonomien als OSCAL-Kataloge - eine Marktneuheit:

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"

OPA-Policy-Template

Entwurf

Beispiel einer Rego-Policy für Beleg-Validierung:

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
}

V7GUID-Schema

Entwurf

Das kanonische V7GUID-Metadaten-Schema:

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"

Compliance-Tiefe → V7GUID-Schema-Tiering

Je nach Integrationstiefe des Git-Repositories und Compliance-Anspruch werden unterschiedliche V7GUID-JSON-Schemata benötigt. Das GCBoK definiert ein Schema-Tiering (Stufenmodell), das an VariantId, kind und status gekoppelt ist:

Tier	Compliance-Anspruch	Erforderliche Schema-Felder	`VariantId`	`kind`	`status`
T1	GoBD/AO only (Minimal)	`v7guid`, `class`, `sha256`, `prev_sha256`, `gpg_fingerprint`, `timestamp_iso`, `gobd_periode`	`10` (10-Jahre-Aufbewahrung §147 AO)	`INVOICE`, `RECEIPT`, `CONTRACT`	`ACTIVE`
T2	PII / DSGVO	T1 + `tenant_id`, `org_unit_id`, `data_category` (Art. 9 DSGVO), `retention_legal_basis`	`11` (DSGVO-Schutzstufe)	`PERSON`, `HR_DATA`	`ACTIVE`
T3	NIS2 (Kritische Infrastrukturen)	T2 + `risk_level`, `incident_reporting_obligation`, `supply_chain_tier`	`12` (NIS2-Risikoklasse)	`INFRASTRUCTURE`, `LOG_DATA`	`ACTIVE`
T4	ISO 27001 (Voll)	T3 + `control_id` (ISO 27001 Annex A), `asset_classification`, `treatment_plan_ref`	`13` (IFRS/HGB + ISO)	`POLICY`, `AUDIT_EVIDENCE`	`ACTIVE`

Prinzip: „Am Ende bleiben nur Git-Repos übrig“ — der Fallback bei Prüfungen/Audits sind Code-Artifacts + .gitcover Registries/Dictionaries im JSON/JSONL-Format. Das HTML-Prüferpaket ist nur Präsentation; die Forensik ist das Git-Repo (siehe Vorgehensweisen: Audit-Readiness und Derivat gcbok-audit-evidence-docs/docs/02-audit-website-als-pruefungsartefakt).

Die Schema-Dateien liegen versioniert im .gitcover/schemas/ des TOP-Repos und werden über others.json auflösbar gemacht.

DMS-Container-Template

Der .v7g.zip-Container für GCDMS (Umfang abhängig von Use Case):

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

Format-Auswahl je nach Use Case

Format	Verwendung
`.v7g.json`	Maschinenlesbar, OPA-Policies, OSCAL-Export
`.v7g.md`	Hyperlinks, menschlich lesbar, Git-Web-UI
`.v7g.yaml`	Konfigurationsfile, Human-Editable

V7GUID-Sidecar-Template

Kanonisches Sidecar (*.v7g.md) für ein digitales Originaldokument. Schema: https://gitcover.org/schemas/v7g-sidecar-1.0.schema.json; die Instanz-Metadaten folgen record-metadata-1.0.schema.json (ISO 15489).

DocID = uuidv7 (Instanz-Identifikator) vs. v7guid (Klassen-/Kontext-Identifikator). Beide werden im Sidecar geführt und über composite_key ({v7guid}:{uuidv7}) verknüpft. Mindestinhalt: sha256 des Originaldokuments.

# 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}"
}
```

DocID-Vergabe: Wird das Dokument neu ins DMS aufgenommen, erzeugt das Sidecar-Tool eine UUIDv7 aus einem TimeStamp-Argument als DocID (uuidV7). Default-Quelle ist die Datei-mtime; liefert Filename oder Inhalt ein fachliches Datum, wird dieses verwendet (siehe Achse 5: Vorgehensweisen).