The application helps DPO, security, and compliance teams discover and map personal or sensitive data with configurable regulation-oriented labels and recommendation text. This document describes which frameworks are explicitly referenced today, where to find sample configuration, and how to extend support to others (e.g. UK GDPR, PIPEDA, APPI, POPIA) without code changes.
Decision-makers (legal / compliance leadership): start with the non-technical summary COMPLIANCE_AND_LEGAL.md (pt-BR); return here for files, samples, and merge steps. For alignment with IT governance and service-management frameworks (ITIL 4, COBIT 2019, ISO/IEC 38500, ISO/IEC 27014, ISO/IEC 20000), see ITSM_GOVERNANCE_ALIGNMENT.md (pt-BR).
Português (Brasil): COMPLIANCE_FRAMEWORKS.pt_BR.md
norm_tag, recommendation overrides, and the Excel workbook remain the primary way to align detection and report wording with each framework profile you merge from compliance-samples/. For CISO/DPO read-outs of a completed scan, the product may also emit executive Markdown and a scan_manifest_*.yaml alongside the XLSX: they summarise execution posture (sampling, timeouts, dialect notes where applicable) and prioritised remediation without pasting sensitive literals—useful when counsel asks both what was labelled and how reads were bounded. They are governance-adjacent artefacts, not a substitute for programme-level GRC tooling or legal sign-off—see Evidence and outputs in COMPLIANCE_AND_LEGAL.md and REPORTS_AND_COMPLIANCE_OUTPUTS.md.
The root README “For decision-makers” section stays in plain stakeholder language (for example sniffing with judgment on the data soup metaphor). It does not require the internal deck labels below.
For slide banks, workshop handouts, and structured compliance technical docs (this page, COMPLIANCE_TECHNICAL_REFERENCE.md, GLOSSARY.md), optional paired labels Data Sniffing (the discovery and sampling pass: connectors, bounded reads, sensitivity detection) and Deep Boring (the structured compliance-report depth: Excel workbooks, norm_tag alignment, recommendation overrides, heatmaps) keep vocabulary stable. They are two halves of one session, not competing features. Internal plans may still say “deep sniffing” or “sniffing harder”; when you promote copy to decks or technical prose for procurement/DPO workshops, you may standardise on Data Sniffing / Deep Boring as defined in GLOSSARY.md—without treating the README executive blurb as the place to introduce those names.
Discovered evidence vs narrated “AI”. The engine produces repeatable findings from regex, named patterns, and supervised ML/DL on your training terms—plus structured signals such as quasi-identifier aggregation, minor-related columns, and jurisdiction hints / tension (always heuristic, never “applicable law” in software). That is a different contract from generative LLMs, which optimise for fluent text and may vary run-to-run. For architecture and audit expectations, see TECH_GUIDE.md; for terminology (LLM, deterministic detection stack, Google Gemini maintainer tooling), see GLOSSARY.md §8–9 and docs/ops/LLM_AGENT_EDITING_CAUTION.md. For a vendor-neutral timeline from 1950s symbolic work through AI winters, expert systems, statistical ML, deep learning, and today’s LLMs—and where each family fits—see AI_EVOLUTION_PRIMER.md (pt-BR).
Built-in (out of the box): The detector and reports explicitly reference LGPD (Brazil), GDPR (EU), CCPA (California), HIPAA (US health), and GLBA (US financial). Findings use these norm tags and recommendation text by default.
Sample configuration and examples: We provide config-file examples so you can align with more regulations without changing code (including per-region YAML profiles under compliance-samples/, e.g. Russia 152-FZ — see List of samples and links):
- regex_overrides.example.yaml – custom regex patterns with
norm_tag(e.g. LGPD Art. 5, CCPA). Copy and extend for other identifiers (e.g. UK NIN, Canadian SIN) and setnorm_tagto your framework. - Recommendation overrides – in USAGE.md (report section) you will find
report.recommendation_overrides: list ofnorm_tag_pattern,base_legal,risk,recommendation,priority,relevant_for. Use this to tailor report text for any regulation (UK GDPR, PIPEDA, POPIA, APPI, PCI-DSS, or internal norms). - ML/DL terms – SENSITIVITY_DETECTION.md and the main config support
ml_patterns_file,dl_patterns_file, or inlinesensitivity_detection.ml_terms/dl_termsso you can add framework-specific terms (e.g. “personal information”, “data subject”, “responsible party”) for better detection and labelling.
Compliance samples (one profile per regulation): Sample configs for UK GDPR, EU GDPR, EU NIS2, Benelux, PIPEDA, POPIA, APPI, PCI-DSS, Russia (Federal Law 152-FZ), and other regions are in compliance-samples/. Each sample is a single YAML file with regex patterns, ML terms, and recommendation overrides for that framework. NIS2 is a cybersecurity directive (not a personal-data law); it complements GDPR because NIS2 incidents often trigger GDPR breach notification in parallel — pair compliance-sample-eu_nis2.yaml with the EU GDPR sample. See the Compliance samples section below for the full list, what goes in which file, and how to use them. For language and target audience (e.g. PIPEDA → EN + FR for Canada; 152-FZ → EN + RU terms in the Russian sample), see the compliance-samples README.
Brazil insurance sector (LGPD anchoring + prudential references) {#brazil-insurance-sector-lgpd-anchoring-prudential-references}
Not legal advice. This subsection orients technical and compliance readers who operate in Brazilian private insurance (SUSEP-supervised undertakings, brokers, and service providers). It is not a substitute for counsel, ANPD guidance, or prudential supervision practice.
What the product does here: Data Boar supports discovery, sampling, and metadata-oriented reporting (including configurable norm_tag text). It does not certify LGPD compliance, SUSEP/CNSP compliance, solvency reporting, licensing, or any supervisory outcome.
LGPD as the primary data-protection anchor: Personal and sensitive data processed in insurance workflows remain subject to the Lei Geral de Proteção de Dados (LGPD). Official text: Planalto — Lei nº 13.709/2018. The ANPD publishes guidance applicable across sectors: gov.br — ANPD.
Prudential and market-conduct layer (sector, not a substitute for LGPD): SUSEP supervises private insurance in Brazil; CNSP (within that policy ecosystem) issues resolutions that firms must operationalise alongside LGPD where personal data is involved. Official entry point for instruments and communications: gov.br — SUSEP. Circular letters and CNSP norms appear in SUSEP’s official legislation / normative channels on the same portal; always use the current consolidated text on gov.br before relying on any deep link.
Optional YAML skeleton: For generic insurance-sector column names and document vocabulary with LGPD-inventory-oriented norm_tag strings (still not a regulatory certification), see compliance-sample-br_insurance_lgpd_anchor.yaml in the table below. Pair it with the full compliance-sample-lgpd.yaml profile when you need Brazilian identifier coverage (CPF, CNPJ, etc.).
Sample configuration files for UK GDPR, EU GDPR, Benelux, PIPEDA, POPIA, APPI, PCI-DSS, Russia (152-FZ), and optional regional frameworks are in compliance-samples/. Each file is self-contained (regex overrides, ML terms, recommendation overrides) so you can enable one framework by pointing your config at that file and merging its overrides.
Laws, guidance, and real-world identifier usage evolve in many sampled jurisdictions—not only those with the fastest statutory churn. Statutes and official texts are also reworded or replaced over time, so YAML that “matched last year” may need updates even when politics are stable. Plan to refresh samples you rely on (regex, terms, overrides) on a cadence that fits your risk—quarterly or before a minor release is a reasonable default for high-stakes profiles; see Sample maintenance in the compliance-samples README. The 152-FZ sample header calls out especially frequent legal churn; treat it as a template for documenting review risk in other jurisdictions.
| Regulation / region | Sample file | Purpose |
|---|---|---|
| LGPD (Brazil) | compliance-sample-lgpd.yaml | Bilingual PT-BR + EN terms; RG/CEP regex; precise geolocation regex (same geometry as VCDPA / EU GDPR sample); Brazilian deployments. |
| Brazil (insurance sector — LGPD inventory skeleton) | compliance-sample-br_insurance_lgpd_anchor.yaml | Generic insurance lexicon + LGPD-anchored norm_tag for inventory; not SUSEP/CNSP certification (see insurance subsection). |
| Brazil (FELCA — Lei 15.211/2025) | compliance-sample-brazil_felca.yaml | Estatuto Digital da Criança e do Adolescente (digital platforms and minors); inventory norm_tag and ML terms; pair with LGPD sample; not age verification (see FELCA bullet under Auditable and management standards and MINOR_DETECTION.md). |
| Brazil (ANPD Res. 2/2022 — Children's data) | compliance-sample-brazil_anpd_res2_2022.yaml | ANPD Resolução CD/ANPD 2/2022 implementing LGPD Art. 14; parental consent (verificável, específico, revogável); behavioural profiling prohibition (norm_tag: perfilamento proibido — menores); educational data restrictions; in force 2023; any entity (not only platforms); complements FELCA + LGPD; PT-BR + EN. |
| Brazil (EAD / education — LGPD Art. 14 + ECA) | compliance-sample-br_ead_lgpd_art14.yaml | Distance-learning and school/LMS inventory: RA / matrícula, .edu.br mail, contextual educational CPF fields (not a bare CPF matcher); ECA (Lei 8.069/1990) + LGPD Art. 14; pair with LGPD + ANPD Res. 2/2022 + FELCA; not age verification or MEC/ANPD certification; PT-BR + EN. |
| Brazil (health sector — LGPD Art. 11) | compliance-sample-brazil_saude.yaml | Health-sector identifiers (CRM/CRF/CRO/COREN, CNS, ANVISA RMS, ANS) and health-data lexicon; pair with LGPD sample; heuristic regex — not CRM checksum validation. |
| Brazil (BACEN Res. 4893/2021 — Cybersecurity) | compliance-sample-brazil_bacen4893.yaml | BACEN cybersecurity policy for banks, fintechs, and payment institutions; Pix keys, account numbers, card tokens, NSU regex; incident notification 4 business days to BACEN (Art. 11); IT outsourcing 3-tier rules (Art. 16); cryptographic controls; in force February 2022; pairs with LGPD + PCI-DSS samples; PT-BR + EN. |
| UK GDPR | compliance-sample-uk_gdpr.yaml | UK post-Brexit, ICO-aligned; norm_tag and recommendation overrides; precise geolocation regex (same geometry as VCDPA / EU GDPR sample). |
| EU GDPR (EEA) | compliance-sample-eu_gdpr.yaml | EU 2016/679 Art. 4(1), EDPB, member-state DPAs; optional EN + DE/FR terms. |
| EU NIS2 (Directive 2022/2555) | compliance-sample-eu_nis2.yaml | Network and Information Security; essential/important entities; cybersecurity measures (Art. 21); incident notification 24h+72h to CSIRT/competent authority (Art. 23); supply chain security; vulnerability disclosure (Art. 12); credentials/keys/MFA-secrets detection; pairs with EU GDPR sample for full EU coverage; not a personal-data law (complements GDPR when incidents also trigger breach notification); transposition deadline 17/10/2024 (application depends on national transposition); EN. |
| Benelux (BE, NL, LU) | compliance-sample-benelux.yaml | EU GDPR base + national IDs (BSN, NISS, LU); national DPA overrides; EN + NL/FR/DE (Belgium's third official language / Ostbelgien). |
| Germany (BDSG) | compliance-sample-germany_bdsg.yaml | BDSG as GDPR national supplement; contextual Steuer-ID / employee / biometric / scoring labels (no nude 11-digit matcher); §26 employee data contested (CJEU C-34/21); §31 scoring; 16 Land DPAs + BfDI; pair with EU GDPR; EN + DE. |
| HIPAA / PHI (US Health) | compliance-sample-us_hipaa_phi.yaml | Privacy Rule (45 CFR Part 164) + Security Rule + Breach Notification Rule + HITECH 2009; HHS OCR; NPI + DEA + MRN + ICD-10 regex; precise geolocation (geographic data < state = PHI Safe Harbor identifier #3); 95+ ML terms; covered entity / BAA / minimum necessary / TPO / ePHI safeguards; psychotherapy notes + 42 CFR Part 2 + GINA; 60-day breach notification; de-identification (Safe Harbor / expert determination); EN. |
| FERPA (US Education) | compliance-sample-us_ferpa.yaml | 20 U.S.C. § 1232g; FPCO; education-record inventory signals; SSN + contextual student ID + DOB regex; precise geolocation (4 patterns); LMS/SIS, transcript, directory information, parent/guardian and school-official vocabulary; pair with COPPA for under-13 web; EN. |
| CMMC / CUI (US Defense) | compliance-sample-us_cmmc_cui.yaml | CUI markings/banners, category labels, dissemination controls (NOFORN, REL TO, …); ITAR/EAR/USML/CCL as inventory/triage signals; ~60 ML terms; supports CMMC evidence / CUI discovery — does not certify CMMC, assess a CMMC level, or determine ITAR/EAR applicability; EN. |
| PIPEDA (Canada) | compliance-sample-pipeda.yaml | Personal information, consent; Canadian identifiers (e.g. SIN); precise geolocation regex (same geometry as VCDPA / EU GDPR sample); EN + FR. |
| Quebec (Law 25) | compliance-sample-canada_qc_law25.yaml | Act respecting the protection of personal information in the private sector (QC, modernized 2023); CAI; complements federal PIPEDA for QC private sector; precise geolocation (4 patterns); EN + FR. |
| POPIA (South Africa) | compliance-sample-popia.yaml | POPIA Act 4/2013; Information Regulator; SA ID regex; precise geolocation (same geometry as VCDPA / EU GDPR); special personal information (s.26), children's data (s.34), cross-border transfers (s.72); EN. |
| APPI (Japan) | compliance-sample-appi.yaml | Personal information and sensitive personal information (要配慮個人情報); My Number; precise geolocation regex (位置情報; same geometry as VCDPA / EU GDPR); EN + Japanese terms; PPC alignment; 2022 revision. |
| PCI-DSS | compliance-sample-pci_dss.yaml | Payment card patterns and recommendation overrides for merchants/assessors. |
| Philippines (DPA) | compliance-sample-philippines_dpa.yaml | RA 10173 + NPC IRR 2016; NPC; SSS/GSIS/TIN/PhilSys regex; precise geolocation; SPI categories (race, health, genetic, criminal, government IDs); 72 h breach notification; EN. |
| Australia (Privacy Act) | compliance-sample-australia_privacy.yaml | Privacy Act 1988 (Cth; 2024 Amendment Act), OAIC, APPs; TFN/Medicare/ABN/Passport regex; precise geolocation (same geometry as VCDPA / EU GDPR); NDB scheme; sensitive information (s.6); EN. |
| Singapore (PDPA) | compliance-sample-singapore_pdpa.yaml | PDPA 2012 (amended 2020/2021), PDPC; NRIC/FIN/UEN regex; precise geolocation (same geometry as VCDPA / EU GDPR); DNC, mandatory breach notification; EN. |
| Malaysia (PDPA + Amd. 2024) | compliance-sample-malaysia_pdpa.yaml | PDPA 2010 + Act A1727 (phases 1 Jan / 1 Apr / 1 Jun 2025, all in force); Commissioner; Data Controller/Processor; DPO; formatted MyKad + contextual labels (no bare 12-digit matcher); biometric as sensitive; precise geolocation (JSON lat/lng + CSV pair); EN. |
| Thailand (PDPA) | compliance-sample-thailand_pdpa.yaml | Personal Data Protection Act B.E. 2562 (2019), PDPC; personal data / sensitive personal data; precise geolocation (4 patterns); EN + Thai. |
| Vietnam (PDPD) | compliance-sample-vietnam_pdpd.yaml | Decree 13/2023/NĐ-CP (effective 1 July 2024); Ministry of Public Security framing; CCCD / legacy CMND patterns; precise geolocation (4 patterns); EN + Vietnamese; extraterritorial scope note in sample header. |
| South Korea (PIPA) | compliance-sample-south_korea_pipa.yaml | PIPA (개인정보 보호법), PIPC; contextual RRN + 사업자등록번호 + passport regex; precise geolocation (4 patterns); 95+ ML terms (EN + Korean): sensitive info, overseas transfer, entrustment, biometrics, CCTV; sector / “three-data” note in sample header. |
| UAE (PDPL) | compliance-sample-uae_pdpl.yaml | Decree-Law 45/2021 + Cabinet Regulations 2023; UAE Data Office (UAEDO/TDRA); Emirates ID regex; precise geolocation; sensitive categories (health, biometric, genetic, racial, religious, criminal, financial, children's data); Free Zone note (DIFC/ADGM); EN + AR. |
| Egypt (PDPL Law 151/2020) | compliance-sample-egypt_pdpl.yaml | Law 151/2020 + Decree 816/2025 (1 Nov 2025); Personal Data Protection Centre (PDPC); contextual national-ID labels (no bare 14-digit matcher); children's data as sensitive; EDM permit signal; precise geolocation (JSON lat/lng + CSV pair); 72 h Centre breach notice; grace until 31 Oct 2026; EN + AR. |
| Argentina (PDPA) | compliance-sample-argentina_pdpa.yaml | Ley 25.326, DNPDP; datos personales; ES + EN; CUIT/CUIL/DNI regex. |
| Kenya (DPA) | compliance-sample-kenya_dpa.yaml | Data Protection Act 2019, ODPC; personal data, data controller. |
| Ethiopia (PDPP 1321/2024) | compliance-sample-ethiopia_pdpp.yaml | Proclamation 1321/2024 (in force 24 Jul 2024); ECA; contextual Fayda FIN labels (no bare 12-digit matcher); biometric (fingerprint/face/iris); precise geolocation (JSON lat/lng + CSV pair); 72 h breach notice (revalidate); EN + draft Amharic (native review recommended). |
| India (DPDP) | compliance-sample-india_dpdp.yaml | DPDP Act 2023, DPBI; Aadhaar/PAN regex; precise geolocation (same geometry as VCDPA / EU GDPR); SDF / cross-border / children's data ML terms; EN; rules evolving — revalidate. |
| Pakistan (PDPA Bill 2023) | compliance-sample-pakistan_pdpa.yaml | Personal Data Protection Bill 2023 (draft as of 2026-08 — not yet enacted); proposed NCPDP (s.35); formatted CNIC + contextual NADRA/NTN/passport labels; s.2(kk) sensitive (CNIC/passport, health, biometric, genetic, religious, political, caste/ethnicity, financial); s.14 children; precise geolocation (JSON lat/lng + CSV pair); EN + Urdu. |
| Indonesia (PDP Law) | compliance-sample-indonesia_pdp.yaml | Law 27/2022 on Personal Data Protection; MOCLA / PDP institution; personal / specific personal data; precise geolocation (4 patterns); EN + Indonesian. |
| China (PIPL) | compliance-sample-china_pipl.yaml | PIPL; CAC; contextual PRC resident ID + Unified Social Credit Code; precise geolocation (4 patterns); sensitive PI, separate consent, cross-border transfer, CII, children's PI; EN + Chinese (UTF-8) terms. |
| Turkey (KVKK) | compliance-sample-turkey_kvkk.yaml | Law 6698 + Amendment 7499 (2024); KVKK Board; TC Kimlik No regex; precise geolocation; sensitive data categories (race, health, biometric, genetic, criminal); VERBİS; 72 h breach notification; EN + TR. |
| Ukraine (PDP Law 2297-VI) | compliance-sample-ukraine_pdp.yaml | Law 2297-VI (2010, amended 2023); GDPR-convergent (EU candidacy 2022); IPN + biometric & legacy Cyrillic passport regex; precise geolocation (4 patterns); 98+ ML terms (EN + Ukrainian); sensitive categories (Art. 7); 72 h breach notification (Law 3454-IX 2023); ROPA, DPIA, DPO; martial law processing exceptions; cross-border transfer safeguards. |
| New Zealand (Privacy Act) | compliance-sample-new_zealand_privacy.yaml | Privacy Act 2020; OPC; IRD/NHI/Passport regex; precise geolocation; 13 IPPs; Notifiable Privacy Breach; sensitive categories (health, biometric, genetic, ethnicity, sexual orientation, financial); IPP 12 trans-border safeguards; EN. |
| Russia (152-FZ) | compliance-sample-russia_152_fz.yaml | Federal Law 152-FZ (266-FZ 2022), Roskomnadzor; precise geolocation; SNILS + heuristic INN regex; special categories (Art. 10); mandatory breach notification (72 h); localization (Art. 22.1); EN + RU terms; revalidate often. |
| Saudi (PDPL) | compliance-sample-saudi_pdpl.yaml | Royal Decree M/19, SDAIA; personal/sensitive data. |
| Israel (PPL + Amd. 13) | compliance-sample-israel_ppl.yaml | PPL 5741-1981 + Amendment 13 (in force 14 Aug 2025); PPA; Controller/Processor; Highly Sensitive Information; contextual teudat-zehut labels (no bare 9-digit matcher); precise geolocation (JSON lat/lng + CSV pair); EN + HE. |
| Colombia (Law 1581) | compliance-sample-colombia_1581.yaml | Ley 1581/2012, SIC; datos personales; ES + EN; CC/NIT regex. |
| Mexico (LFPDPPP) | compliance-sample-mexico_lfpdppp.yaml | LFPDPPP, INAI; datos personales / sensibles, ARCO, aviso de privacidad; contextual CURP/RFC; precise geolocation (4 patterns); ES + EN. |
| Chile (Privacy) | compliance-sample-chile_privacy.yaml | Law 19.628; datos personales; ES + EN; RUT regex. |
| Ecuador (LOPDP — 2021) | compliance-sample-ecuador_lopdp.yaml | Ley Orgánica de Protección de Datos Personales; APDP; contextual cédula/RUC/passport labels; migratory status as sensitive (Art. 4/25 — unusual among LatAm); precise geolocation (JSON lat/lng + CSV pair); children's data (Art. 25); Art. 43 breach notification (five days); GDPR-influenced; full enforcement May 2023; ES + EN. |
| Peru (Ley 29733 — 2011) | compliance-sample-peru_ley29733.yaml | Ley de Protección de Datos Personales + DS 003-2013-JUS; ANPDP; contextual DNI/RUC/passport/CE labels (no nude digit matchers); Art. 2.5 sensitive (health, ingresos económicos, convictions/union); Art. 13.6 written consent; Art. 17 confidentiality duty; precise geolocation (JSON lat/lng + CSV pair); OECD accession candidate (roadmap 2022 — not a member as of 2026-08); ES + EN. |
| Nigeria (NDPR) | compliance-sample-nigeria_ndpr.yaml | NDPR 2019, NITDA; personal data, data controller. |
| Morocco (Law 09-08) | compliance-sample-morocco_09_08.yaml | Law 09-08, CNDP; données à caractère personnel; FR + EN; CIN regex. |
| Switzerland (FADP) | compliance-sample-switzerland_fadp.yaml | Revised FADP, FDPIC; personal data; EN + optional DE/FR/IT; AHV/UID regex. |
| U.S. (FTC COPPA) | compliance-sample-us_ftc_coppa.yaml | 15 U.S.C. §§ 6501-6506 + 16 CFR Part 312; FTC 2024 amendment; precise geolocation; COPPA_UNDER13_REF/VPC regex; safe harbors; ed-tech carve-out; 2024 rulemaking (biometric, targeted ads); civil penalty framing; technical mapping only. |
| U.S. (CA AB 2273) | compliance-sample-us_ca_ab2273_caadca.yaml | California Age-Appropriate Design Code labelling; applicability varies—counsel required; precise geolocation regex (same geometry as VCDPA / EU GDPR sample) for inventory signals. |
| U.S. (CO CPA — minors) | compliance-sample-us_co_cpa_minors.yaml | Colorado Privacy Act / under-18 contexts technical mapping; not “known minor” detection. |
| U.S. (Virginia — VCDPA) | compliance-sample-us_va_vcdpa.yaml | Virginia Consumer Data Protection Act: sensitive lexicon + precision geolocation regexes; no automatic B2B/employment exemption analysis — see sample header. |
| U.S. (California — CPRA/CCPA) | compliance-sample-us_ca_cpra.yaml | CCPA as amended by CPRA: exports built-in CCPA_SSN + CA DL / ITIN; precise geolocation SPI (§ 1798.140(ae)(1)(H)); consumer-privacy ML terms; CPPA framing. |
| U.S. (FCPA / internal policy pack) | compliance-sample-us_fcpa_internal_policy_pack.yaml | FCPA-adjacent and employer anti-corruption policy lexicon (inventory); not bribery detection or legal conclusion. |
Each sample can provide up to three kinds of content. Your main config references or merges them as follows:
| Config key / file | Purpose | What the sample provides |
|---|---|---|
regex_overrides_file / regex_overrides_files |
Custom regex patterns; match → finding with HIGH and given norm_tag. |
A list of { name, pattern, norm_tag } (e.g. UK NIN, Canadian SIN, SA ID). Samples may use key regex or patterns. |
ml_patterns_file / ml_patterns_files / sensitivity_detection.ml_terms |
ML (and DL) training terms; column names and sample text classified as sensitive/non_sensitive. | A list of { text, label } with framework-specific terms (e.g. “data subject”, “personal information”, “responsible party”). Samples may use key terms or ml_terms. |
report.recommendation_overrides |
Override “Base legal”, “Risco”, “Recomendação”, “Prioridade”, “Relevante para” per norm_tag. |
Loaded automatically from each sample you reference (see below). Extra inline rows still win on the same norm_tag_pattern. |
The same YAML file can contain regex, terms, and recommendation_overrides. Point regex_overrides_file / ml_patterns_file (or the plural list keys / compliance_frameworks) at that file; the loader injects recommendation_overrides into report.recommendation_overrides (no manual copy). Inline report.recommendation_overrides still win on the same norm_tag_pattern.
Compliance sample patterns and terms are merged with (not a replacement for) the built-in detector patterns:
regex_overrides_file/regex_overrides_files— the detector runs both the built-in patterns (CPF, CNPJ, email, phone, SSN, credit card, …) and the patterns in your sample file(s). If a built-in pattern has the samenameas one in an overrides file, the override wins for that specific name. Later files in a list win on the samename. Patterns with unique names are added on top.ml_patterns_file/sensitivity_detection.ml_terms— your terms are merged with the default built-in ML terms. When you loadcompliance-sample-eu_gdpr.yamlalongside your LGPD base config, the detector trains on LGPD built-in terms plus the GDPR terms from the sample — it does not drop LGPD coverage.report.recommendation_overrides— the list is evaluated top-to-bottom using first-match substring semantics onnorm_tag_pattern. Order matters: put more specific patterns (e.g."UK GDPR") before broader ones (e.g."GDPR") so"UK GDPR"findings do not accidentally match the"GDPR"rule first.
To remove a built-in pattern (rare), set it in sensitivity_detection.exclude_patterns or supply an ml_patterns_file that explicitly does not include those terms.
When a finding matches patterns from two or more jurisdictions simultaneously (e.g. an email address in a database that also contains EU data subject references and Brazilian CPF numbers), the detector reports all matching norm_tags — the behavior is additive, not exclusive:
- The finding gets all applicable
norm_tagvalues (union, not winner-take-all). - The report shows each norm_tag row in the Recommendations sheet, using the first matching
recommendation_overridesentry for each. - There is no automatic tie-breaker that "picks" LGPD over GDPR or vice versa; that judgment is left to DPOs and counsel, per ADR 0025 and ADR 0038.
- When two overlapping
norm_tag_patternentries exist inrecommendation_overrides, the first match in list order determines the recommendation text for that pattern. Order the list from most specific to least specific to get predictable output. - The jurisdiction hints layer (
report.jurisdiction_hints) is a separate, per-session heuristic signal — see JURISDICTION_COLLISION_HANDLING.md for the counsel-facing framing.
-
Choose the sample for your regulation from the table above (or from compliance-samples/README.md).
-
Set paths in your main config (e.g.
config.yaml). One framework:regex_overrides_file: docs/compliance-samples/compliance-sample-pipeda.yaml ml_patterns_file: docs/compliance-samples/compliance-sample-pipeda.yaml
Several frameworks (same merge order as
sql_sampling_files: later file wins on the same regexname, MLtext, ornorm_tag_pattern):compliance_frameworks: [lgpd, pci_dss, brazil_saude]
Or list files yourself:
regex_overrides_files:/ml_patterns_files:.Use the same file for regex and ML if the sample contains both
regexandterms. -
Recommendation text is injected automatically from each referenced sample into
report.recommendation_overrides. Add extra inline rows only if you need to override a sample’s wording. See USAGE.md (report section). Put more specificnorm_tag_patternvalues before broader substrings when you add inline rows (first-match). -
Run the scan (CLI or API). Findings will use the norm tags and recommendation text from the sample; the Excel report will show the framework-specific Base legal, Risco, Recomendação, and Prioridade.
Multi-language, multi-encoding, and multi-regional operation {#multi-language-multi-encoding-and-multi-regional-operation}
Whatever the language, encoding, or region of your data soup, the application is built to handle it: you can run compliance scans and reports in the language and encoding of your region without breaking in production.
- Multiple languages in terms and reports: Compliance samples can include terms in the language(s) of the target region (e.g. EN+FR for PIPEDA/Canada, PT-BR+EN for LGPD/Brazil, Japanese or Arabic for APAC/MENA, EN+RU for Russia 152-FZ). The Excel report and recommendation text support Unicode (e.g. base_legal and recommendation in Japanese, Arabic, Cyrillic, or accented characters).
- Scripts and charset behaviour in data: The scan and report pipeline is Unicode-first. Real-world content often mixes Latin, Cyrillic (e.g. Russian), CJK (e.g. Japanese kanji/kana), and Arabic script (including RTL presentation where the viewer supports it). Unusual or legacy byte encodings for configs and pattern files are handled via auto-detection (main config) and
pattern_files_encoding(pattern files); encoding sniffing and heuristics for specific corpora can be tuned further (config, patterns, connectors) when a deployment needs stricter behaviour—contact us for consulting if your IT, security, compliance, or DPO teams require a custom language/encoding profile. - Multiple encodings for config and pattern files: The main config file is read with auto-detection (UTF-8, UTF-8 with BOM, Windows ANSI/cp1252, Latin-1), so it loads even when saved in a legacy encoding. Pattern files (regex overrides, ML/DL terms) use the encoding set by
pattern_files_encodingin your config (defaultutf-8). Set it tocp1252orlatin_1only when your pattern or sample files are saved in that encoding. - Multiple regions: Use the compliance sample that matches your region or regulation (LGPD, UK GDPR, EU GDPR, Benelux, PIPEDA, POPIA, APPI, PCI-DSS, 152-FZ, or optional regional samples). Each sample is a single YAML file. Point
regex_overrides_fileat it, or setcompliance_frameworks: [lgpd, pci_dss, …]. Recommendation overrides are injected automatically.
Today, tracked product documentation is English + pt-BR; the dashBOARd web UI is largely English in templates. Many locales people ask for are not shipped yet—full dashboard and documentation surfaces in additional human languages and scripts (e.g. es, fr, ja, ru, ar, plus Mandarin / Cantonese, Indonesian, Korean, Thai, Vietnamese, Hindi and other Indic scripts, Ethiopian / Amharic, broader African contexts, Catalan, Basque, Galician, and more) sit on a short- to mid-range, demand-driven roadmap together with matching compliance-sample profiles where regulations warrant them. We welcome public suggestions (issues or discussions) on locale or encoding gaps; commercial consulting can accelerate tailored wording, samples, or integration hooks where the open defaults are not enough. A public summary of this direction (without internal planning filenames) is in the Roadmap — internationalization and regional depth paragraph in the repository README.md (pt-BR).
-
Choose the right sample for your region
See the compliance-samples README table and the “Language and target audience” section. For example: Brazil → LGPD (PT-BR+EN); Canada → PIPEDA (EN+FR); UK → UK GDPR; EEA → EU GDPR; Benelux → Benelux sample; Japan → APPI; South Africa → POPIA; Russia → 152-FZ (EN+RU terms; revalidate often).
-
Save config and sample files in UTF-8 (recommended)
Saving everything in UTF-8 avoids encoding issues with multilingual terms. The main config file will still load if it is in another encoding (auto-detection).
-
Set paths and encoding in your config
In your main
config.yaml(orconfig.json):# Optional: only if your pattern/sample files are NOT in UTF-8 (e.g. legacy cp1252) pattern_files_encoding: utf-8 regex_overrides_file: docs/compliance-samples/compliance-sample-pipeda.yaml ml_patterns_file: docs/compliance-samples/compliance-sample-pipeda.yaml
Sample
recommendation_overridesare merged intoreport.recommendation_overridesautomatically (see USAGE report section). Add inline rows only to override a sample. -
Run the scan
Use the CLI or API as usual. Findings will use the norm tags and recommendation text from the sample; the Excel report will show Unicode correctly.
For full encoding options and examples, see USAGE – File encoding (EN) and USAGE.pt_BR – Encoding de arquivos (pt-BR).
Assistance with tuning: If your organization needs further or better compatibility with a specific regulation or compliance scope (e.g. VCDPA, CPA, sector-specific rules), we can assist—by creating tailored configuration files or making slight code-side adjustments—when you reach out. This helps potential customers adopt the tool for their jurisdiction or auditor expectations without starting from scratch.
Cyber and AI governance frameworks (evidence, not samples) {#cyber-ai-governance-evidence-not-samples}
Some buyer and auditor conversations cite NIS2, DORA, and the EU AI Act. Those instruments are primarily cybersecurity, ICT operational resilience, or AI-governance frameworks—not PII/CUI vocabulary packs. Data Boar supports them via evidence and inventory (data mapping that can feed asset registers, ICT registers, or low-risk AI positioning for a deterministic, no-LLM scanner). Do not expect or ship a compliance-sample-*.yaml for NIS2, DORA, or the EU AI Act: that would be a category mismatch and an overclaim risk. For CMMC, the fit is different: CUI discovery is data discovery—see compliance-sample-us_cmmc_cui.yaml.
Auditable and management standards (supporting role) {#auditable-and-management-standards-supporting-role}
The application does not certify organisations. It provides discovery and mapping of personal and sensitive data and metadata-only reporting, which supports evidence-based accountability and audit preparation.
ISO 31000 is a guideline for organizational risk management (context, assessment, treatment, monitoring)—not a product control catalogue, and not summarized here. Positioning: your organization’s risk management process should guide prioritization of which systems to scan, which remediations to pursue first, and which regulatory profiles to enable. Data Boar supports evidence (discovery, mapping, metadata-only reports) and does not replace your risk analysis, risk acceptance, or governance decisions. Software supply chain and incident-response inventory (SBOM for dependencies and images) are documented separately as security / release practice—see SECURITY.md, RELEASE_INTEGRITY.md, and ADR 0003—and are not a stand-in for ISO 31000.
- ISO/IEC 27701 (PIMS): ISO/IEC 27701 requires PII controllers and processors to know where PII is and to document the scope of processing. Our scans and reports (findings, norm tags, Excel output) help you produce that evidence and align with the regulations you declare under ISO/IEC 27701 (e.g. LGPD, GDPR, CCPA). Technical scope: COMPLIANCE_TECHNICAL_REFERENCE.md.
- SOC 2: A common pressure point for corporates; SOC 2 (Type I/II) expects documented controls over the security, availability, and confidentiality of systems that process sensitive data. We do not perform SOC 2 audits. Our discovery and mapping of where personal or sensitive data resides, plus metadata-only reporting, supports control design and audit preparation (e.g. evidence of data inventory and scope). Norm tags and recommendation overrides can be aligned to the trust principles and criteria you use.
- FELCA (Lei 15.211/2025 – Estatuto Digital da Criança e do Adolescente): In force from 17 March 2026, FELCA applies to digital platforms directed at or accessible by minors in Brazil. We do not implement age verification or platform controls. Our minor data detection (e.g. date-of-birth and age-related columns, “possible minor” flags) and reports help you map where data relating to minors is processed and support transparency and accountability (e.g. toward ANPD). Complementary opt-in inventory for LGPD Art. 14 (any entity, not only platforms): ANPD Res. 2/2022 sample. Technical notes: MINOR_DETECTION.md.
Other compliance to watch: Regional child-protection or platform laws (beyond FELCA), sector-specific rules (e.g. health, finance), and new data-localisation or cross-border requirements may affect your scope. We extend support via config and compliance-samples as norms become relevant; no code change is required to add new norm tags or recommendation text.
Extended sensitive categories (clinical adjacency, IP indicators, security artifacts in stored data): The same engine can be tuned for additional lexicons and regex shapes—often with consulting to scope targets and reduce false positives. Positioning for buyers and DPOs (without linking to internal PMO detail): COMPLIANCE_AND_LEGAL.md.
U.S. child and minor privacy (technical only): Optional samples (FTC COPPA framing, California AB 2273, Colorado CPA minors context) add norm tags and report wording for audit prep, DPO review, and operational scoping. They do not provide legal advice, verify parental consent, or prove compliance. Disclaimers and sample intent: COMPLIANCE_TECHNICAL_REFERENCE.md and each YAML file’s header comments under compliance-samples/.
Other auditable or regional norms can be addressed via our config-driven norm tags and compliance-samples; we continue to extend documentation and samples as new standards become relevant.
Status: Final text expected 2025–2026 (public draft available at https://pages.nist.gov/800-63-4/). Not yet a built-in norm tag; documented here for integrators and DPOs.
SP 800-63-4 explicitly classifies identity data (name, date of birth, address, national identifiers, biometric data) collected during digital identity proofing as PII. Data Boar detects these exact data classes in databases, filesystems, and APIs.
Practical alignment: Organizations running identity-proofing programmes or managing credential stores can use Data Boar scans to locate where identity-proofing PII resides across their data estate — supporting evidence for a SP 800-63-4-informed data inventory. Pair with the LGPD or GDPR compliance-sample profile to align norm_tag text to local regulation while referencing NIST 800-63-4 scope in DPO reports.
The built-in regex patterns and report labels refer to these frameworks (with example norm_tag values):
| Framework | Scope | Example norm_tag (in reports) |
|---|---|---|
| LGPD | Brazil – Lei Geral de Proteção de Dados | LGPD Art. 5 |
| GDPR | EU – General Data Protection Regulation | GDPR Art. 4(1) |
| CCPA | California – Consumer Privacy Act | CCPA |
| HIPAA | US – Health data | Health/insurance context |
| GLBA | US – Financial services | PCI/GLBA (e.g. credit card) |
Findings are stored with a free-form norm_tag and pattern_detected; the Excel report uses them in the Recommendations sheet (Base legal, Risco, Recomendação, Prioridade, Relevante para).
norm_tagandpattern_detectedare open: you can set them to any framework or internal label.- Regex overrides: Use regex_overrides_file to add patterns and set
norm_tagto e.g."UK GDPR","PIPEDA s. 2","APPI","POPIA"so they appear in reports and recommendations. - Recommendation overrides (config): Use
report.recommendation_overridesin config to tailor "Base legal", "Relevante para", and other recommendation text pernorm_tagpattern—so UK GDPR, PIPEDA, APPI, POPIA, or custom norms get the right labels and text without changing code. See USAGE.md (report section) for an example. - Custom connectors: New data sources can emit findings with any
norm_tag; reporting and recommendations will use config overrides when provided, otherwise the built-in fallbacks.
No change to detector logic or thresholds is required; extensibility is via config and optional override files.
Point-in-time privacy scans plus manual spreadsheets accumulate two debts that usually surface only after harm:
Compliance toil: repetitive, non-scalable work that grows with the estate. When an incident hits, the war room starts with a question that has no fast answer:
“What was the exposure state before this?”
Hours go to archaeology (scattered logs, stale reports, unversioned spreadsheet attachments) instead of containment.
Stale data in automation: worse than no automation is treating last month’s scan as current truth. A scan interpreted weeks later can hide new sensitive holdings. Risk decisions then rest on a map that no longer matches the terrain.
| Debt | Data Boar mechanism | Where it is recorded |
|---|---|---|
| Toil — “what was the state before?” | Immutable Audit Trail + per-session manifest | audit_log (SQLite) + manifest in the output directory |
| Stale data | Session delta (findings_count new vs resolved by pattern) |
Executive report + optional corporate findings sink (GitHub #552) |
| War room without a baseline | Traceable session timestamp + scan history in SQLite | scan_sessions table |
| Undocumented scope | Manifest lists covered sources and explicit exclusions | Session manifest (excluded sources when configured) |
Privacy operations deserve an SLA, not only a paper policy. Measurable criteria with baseline, deadline, and evidence:
| Criterion | Example commitment | Evidence |
|---|---|---|
| Coverage | Configured sources scanned each session | Session manifest |
| Detection | New sensitive holdings visible within N days | Delta between sessions |
| Notification | DPO report within X hours | Timestamp on the Audit Trail |
| Remediation | Every P0/P1 linked to an ITSM ticket within Z days | Findings sink / ticket id when integrated |
When a regulator or external auditor asks how you know sensitive data was mapped, the answer is the manifest, the delta, and the agreed coverage SLA — not a verbal claim.
The session manifest is CI/CD-consumable:
- Unlinked new P0/P1 findings can fail a merge (organisational policy; the product supplies the artefacts).
- Session deltas can feed near-real-time compliance dashboards.
- The findings sink (GitHub #552) can echo findings to a corporate database without replicating sensitive literals (
include_sample_content: falseby default — LGPD Art. 46 posture).
See also: ITSM_GOVERNANCE_ALIGNMENT.md (ITIL / COBIT / ISO 38500 / 27014 / 20000 mapping). A dedicated governance/service-management primer is tracked as GitHub #555 (file not in tree yet). Terms: GLOSSARY.md (compliance toil, stale data, privacy SLA, Governance Lens).
Documentation index (all topics, both languages): README.md · README.pt_BR.md. For configuration schema and report options, see USAGE.md (pt-BR) and TECH_GUIDE.md (pt-BR).