| name | arckit-nl-tbb |
| description | [COMMUNITY] Determine the Te Beschermen Belangen (TBB) category for a system or dataset using the BIV scoring method from the TBB systematiek toolkit, with any existing VIRBI 2025 rubricering applied as a floor |
⚠️ Community-contributed command — not part of the officially-maintained ArcKit baseline. Output should be reviewed by qualified counsel and the departmental security officer before reliance. Citations to VIRBI 2025 and the TBB systematiek may lag the current text — verify against the source.
You are helping an enterprise architect determine the Te Beschermen Belangen (TBB) category for a system or dataset, using the TBB systematiek — "Gereedschap: Te Beschermen Belangen", v1.0, 6 June 2026, part of the Toolkit VIRBI 2025. Its legal basis is the Besluit BVA-stelsel Rijksdienst 2021 (BWBR0044617). The TBB category is the input other Dutch government cloud and security commands (/skill:arckit-nl-cloud, /skill:arckit-nl-bio) consume — determine it here rather than re-deriving it downstream.
User Input
$ARGUMENTS
Instructions
Note: Before generating, scan projects/ for existing project directories. For each project, list all ARC-*.md artifacts, check external/ for reference documents, and check 000-global/ for cross-project policies. If no external docs exist but they would improve output, ask the user.
Step 0: Read existing artifacts from the project context
MANDATORY (warn if missing):
- REQ (Requirements) — Extract: system description, data types processed, sensitivity indicators, security NFRs (NFR-SEC-xxx)
- If missing: warn that a TBB determination requires a minimum understanding of what information the system handles
RECOMMENDED (read if available, note if missing):
- DATA (Data Model) — Extract: data assets, existing classification markers, data flows
- RISK (Risk Register) — Extract: existing risks tied to information sensitivity
OPTIONAL (read if available, skip silently):
- PRIN (Architecture Principles, 000-global) — Extract: any existing information classification policy
Step 0b: Read external documents and policies
- Read any external documents in
external/ — extract prior classification decisions, existing Stg.-marked material, correspondence referencing VIRBI
- Read any global policies in
000-global/policies/ — extract information classification policy
- If any source material cites VIRBI 2013, flag it explicitly as stale: VIRBI 2025 (BWBR0051482, in force 9 September 2025) replaced and repealed VIRBI 2013 on that date.
Step 1: Identify or Create Project
Identify the target project from the hook context. If the project doesn't exist:
- Use Glob to list
projects/*/ directories and find the highest NNN-* number
- Calculate the next number (zero-padded to 3 digits)
- Slugify the project name
- Use the Write tool to create
projects/{NNN}-{slug}/README.md
- Set
PROJECT_ID and PROJECT_PATH
Step 2: Read Source Artifacts
Read all documents from Step 0. Extract the information types, users, and existing markings relevant to the determination.
Step 3: Template Reading
Read the template (with user override support):
- First, check if
.arckit/templates/nl-tbb-template.md exists in the project root
- If found: Read the user's customized template
- If not found: Read
.arckit/templates/nl-tbb-template.md
Also read .arckit/templates/_partials/RENDERING.md — the template's <!-- DOC-CONTROL-HEADER --> marker is resolved against these rules before the artefact is written (see Step 10).
Step 4: Kernbelangen Relevance Assessment
Assess the relevance of each of the five kernbelangen to the information or process in scope: Democratische rechtsorde; Internationale betrekkingen; Veiligheid; Gevoelige beleidszaken; Betrouwbare dienstverlening. Note which are relevant and why — this frames the BIV scoring that follows.
Step 5: BIV Scoring
Score Beschikbaarheid, Integriteit, and Vertrouwelijkheid independently, each on the same four-point scale: Zeer Hoog / Hoog / Midden / Laag. Score each on the impact of loss of that property — do not let one property's score influence another's.
Step 6: TBB Category Determination
CRITICAL: The TBB category is set by the highest of the three BIV scores, not an average and not confidentiality alone. If Beschikbaarheid scores Hoog while Integriteit and Vertrouwelijkheid score Laag, the TBB category is still driven by the Hoog score.
Apply the fixed mapping:
| Highest BIV score | TBB category |
|---|
| Zeer Hoog | TBB 1 |
| Hoog | TBB 2 |
| Midden | TBB 3 |
| Laag | TBB 4 |
The scale runs backwards to its numbering: TBB 1 is the most sensitive category and TBB 4 the least, so a lower number means higher sensitivity. Never treat "a higher TBB category" as meaning a larger number. Every comparison in Step 7 is a comparison of sensitivity, not of the digit.
Step 7: Apply the Existing Rubricering as a Floor on the Category
This command never produces a rubricering. The systematiek treats the rubricering as an input to the TBB determination, not an output of it — §2.1 lists "het rubriceringsniveau van de informatie of van het informatiesysteem" first among the criteria the categorisation must take into account.
Record the rubricering the information in scope already carries, if any. Then apply the one direction the systematiek authorises (§3.1: "Andersom geldt dit echter wel. Indien een proces of informatiesysteem gegevens verwerkt of bevat op het niveau van STG GEHEIM, dan is automatisch sprake van indeling in categorie TBB 2.") as a floor on the category from Step 6:
| Existing marking on the information | Floor: category is at least this sensitive |
|---|
| Stg. ZEER GEHEIM | TBB 1 |
| Stg. GEHEIM | TBB 2 |
| Stg. CONFIDENTIEEL | TBB 3 |
| Departementaal VERTROUWELIJK / ongerubriceerd met merking | TBB 4 |
| None recorded | no floor — Step 6 stands |
Only the Stg. GEHEIM → TBB 2 row is stated outright in §3.1. The other three apply the same authorised direction across the pairings Tabel B sets out; they are an extension of the quoted rule, not a second quotation of it, and they run in the safe direction because a floor can only ever raise sensitivity.
Resolve the two bounds by sensitivity, not by digit. Take the more sensitive of the BIV-derived category (Step 6) and the floor, which is the one with the lower number:
| Category from BIV | Floor from marking | Final category | Bound that applied |
|---|
| TBB 4 | TBB 3 | TBB 3 | floor (more sensitive) |
| TBB 2 | TBB 3 | TBB 2 | highest BIV score (more sensitive) |
| TBB 3 | none recorded | TBB 3 | highest BIV score |
Record both bounds and identify which applied. The floor can only ever make the category more sensitive; it never makes it less. Worked example: BIV scoring yields TBB 4 while the information carries Stg. CONFIDENTIEEL, so the floor is TBB 3 and the final category is TBB 3 — which triggers the clause 5.2 public-cloud prohibition that TBB 4 does not. Leaving it at TBB 4 because "4 is at least 3" is the error this step exists to prevent.
Where the information carries no marking, do not infer one. Report "None recorded" and leave the rubricering unstated.
Step 8: State the One-Way Inference Warning
MANDATORY — do not omit or soften this: The relationship between Stg. classification and TBB category is not symmetrical. The systematiek states both halves itself, immediately beneath Tabel B in §3.1:
Let wel, wanneer een te beschermen belang ingedeeld is in categorie TBB 2, hoeft dit niet te betekenen dat het proces of informatiesysteem gegevens verwerkt of bevat op het niveau van STG GEHEIM. Er kunnen andere redenen zijn waarom een proces of informatiesysteem een dergelijke TBB classificering heeft gekregen.
Andersom geldt dit echter wel. Indien een proces of informatiesysteem gegevens verwerkt of bevat op het niveau van STG GEHEIM, dan is automatisch sprake van indeling in categorie TBB 2.
- Valid (Step 7): information already marked at Stg. GEHEIM implies TBB 2.
- Invalid: a process determined to be TBB 2 does not mean the information it holds is Stg. GEHEIM.
The category is set by the highest of the three BIV scores, which may be an availability or integrity score. §2.1 notes that for VIRBI purposes the confidentiality aspect is the one that matters — "(Voor het VIRBI kijken we slechts/vooral naar Vertrouwelijkheid.)" — so a category driven by Beschikbaarheid says nothing about how the information must be marked.
Tabel B may be reproduced in the artefact as a reference, but only with the caveat above attached, and never executed as a lookup that yields a marking. Determining a rubricering is an act reserved to the departmental security authority under the Besluit BVA-stelsel Rijksdienst 2021; nothing this command produces licenses handling unmarked information as though it were gerubriceerd.
State this explicitly and prominently in the generated document.
Step 9: Downstream Implications
State whether the determined TBB category triggers the clause 5.2 public-cloud prohibition (TBB 1–3), and point to /skill:arckit-nl-cloud for the full eligibility assessment. Note that the BIV scores also feed /skill:arckit-nl-bio control prioritisation.
Step 10: Generate the Determination Document
CRITICAL: Use the Write tool to create the determination document.
-
Use node scripts/generate-document-id.mjs <PROJECT_ID> TBB --filename for the artefact filename.
-
Auto-populate Document Control:
- Document ID: the filename from step 1, without the
.md extension
- Status: DRAFT
- Created Date: {current_date}
- Next Review Date: {current_date + 12 months}
-
Resolve the <!-- DOC-CONTROL-HEADER --> marker per RENDERING.md before writing the artefact. RENDERING.md hard-routes the NL regime to _partials/document-control-nl.md, which already carries the VIRBI 2025 rubricering ladder — no per-command classification override is needed.
-
Populate the External References section per .arckit/references/citation-instructions.md. VIRBI 2025 (BWBR0051482) MUST appear in the Document Register with its primary URL and the verification date.
Before writing the file, read .arckit/references/quality-checklist.md and verify all Common Checks plus the TBB per-type checks pass — including that the one-way inference warning is present and not stated in reverse anywhere in the document.
Write the document to:
projects/{project_id}/<filename>
Step 11: Summary Output
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ TBB Category Determination Generated
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📄 Document: projects/{project_id}/ARC-{PROJECT_ID}-TBB-v{VERSION}.md
📋 Document ID: {document_id}
📅 Assessment Date: {date}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📊 BIV Scores
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Beschikbaarheid: {score}
Integriteit: {score}
Vertrouwelijkheid: {score}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ TBB category: {TBB 1 / 2 / 3 / 4}
🔒 Existing marking in scope: {rubricering already carried, or "none recorded"}
📐 Bound that applied: {highest BIV score / floor from existing marking}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠️ Reminder: this determination produces NO rubricering. A {TBB category}
process does NOT mean the information it holds is gerubriceerd at the
corresponding level. Marking is an act of the departmental security
authority, not an output of the TBB systematiek.
Next steps:
1. {If cloud hosting under consideration: Run /skill:arckit-nl-cloud for the clause 5.2 eligibility check}
2. Run /skill:arckit-nl-bio to prioritise BIO2 controls using these BIV scores
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Important Notes
- The highest score wins: Never average the three BIV scores. Never let Vertrouwelijkheid alone decide the category if Beschikbaarheid or Integriteit scored higher.
- One-way inference is not optional framing: This is the single most important thing this command must get right. A TBB 2 process is not automatically holding Stg. GEHEIM data. Reversing the inference silently mis-classifies data downstream and can cause an eligible cloud hosting decision to be blocked, or worse, an ineligible one to look eligible.
- This command produces no rubricering at all: the systematiek takes the rubricering as an input to the categorisation (§2.1) and states that only the marking-to-category direction holds (§3.1). Step 7 therefore reads an existing marking and applies it as a floor; it never derives a marking from the category. If a downstream artefact needs a rubricering, it comes from the information's own marking or from the departmental security authority — never from this document.
- VIRBI 2013 is stale: If prior assessments or source documents cite VIRBI 2013, flag it — VIRBI 2025 replaced and repealed it on 9 September 2025.
- This command determines the category; it does not determine the hosting decision. Run
/skill:arckit-nl-cloud for the eligibility consequence.
- Use Write Tool: This determination is consumed by other commands — always use the Write tool so it can be read back reliably.
Key References
Note for reviewers: VIRBI 2025 replaced and repealed VIRBI 2013 on 9 September 2025 — material still referencing VIRBI 2013 is out of date. The TBB systematiek's five kernbelangen (Democratische rechtsorde, Internationale betrekkingen, Veiligheid, Gevoelige beleidszaken, Betrouwbare dienstverlening) frame the assessment; the actual category is set by the highest of the three BIV scores, raised to a floor where the information already carries a marking. The inference runs from an established Stg. classification to a TBB category only — the systematiek states in §3.1 that the reverse "hoeft dit niet te betekenen", so this command emits no rubricering.
Success Criteria
- ✅ Determination document created at
projects/{project_id}/ARC-{PROJECT_ID}-TBB-v{VERSION}.md
- ✅ All five kernbelangen assessed for relevance
- ✅ Beschikbaarheid, Integriteit, and Vertrouwelijkheid scored independently
- ✅ TBB category set from the highest of the three scores, with the derivation shown
- ✅ Existing rubricering recorded and applied as a floor; no rubricering derived from the category
- ✅ One-way inference warning stated prominently and correctly
- ✅ VIRBI 2013 flagged as superseded if referenced anywhere in source material
- ✅ Downstream cloud-eligibility implication stated where TBB 1–3 applies
Example Usage
/skill:arckit-nl-tbb Determine the TBB category for a ministry case-file system handling internal audit findings and sensitive policy correspondence
/skill:arckit-nl-tbb TBB determination for 001, citizen-facing benefits platform processing large-scale personal data, no prior classification on record
/skill:arckit-nl-tbb Assess TBB category for an interdepartmental coordination system touching international relations correspondence
Suggested Next Steps
After completing this command, consider running:
/skill:arckit-nl-cloud -- Feed the determined TBB category into the clause 5.2 cloud eligibility check (when TBB category determined and cloud hosting is under consideration for this system)/skill:arckit-nl-bio -- Use the TBB-derived BIV scores to prioritise BIO2 control assessment (when BIO2 conformance assessment for this system has not yet incorporated the BIV scores)/skill:arckit-risk -- Reflect the TBB category and any Stg. classification implications in the risk register (when Risks tied to information classification are not yet reflected in ARC--RISK)*
