How to write a custom PII rule for your industry

Every industry has its own format for sensitive identifiers. A Dutch BSN (citizen service number) is nine digits with a specific checksum. A German health insurance number follows a different pattern. An IBAN in France looks different from one in the Netherlands. Off-the-shelf PII detectors handle the common cases, but your specific business probably has identifiers that aren't in the default set.

What Presidio covers out of the box

Microsoft Presidio, which powers Guarrix's detection engine, ships with recognisers for names, emails, phone numbers, credit card numbers, IBANs, and about forty other entity types across multiple locales. For most B2C applications this covers the majority of PII exposure risk.

What it doesn't cover: your customer reference number format, your internal employee ID scheme, your policy number structure, or any domain-specific identifier that's unique to your business or vertical.

Two approaches: regex and keyword

The simplest custom rule is a regex pattern. If your policy numbers follow a pattern like POL-2026-XXXXXX where XXXXXX is a six-digit number, a regex like POL-\d{4}-\d{6} catches them reliably.

Keyword rules are useful for categorical triggers. If any prompt containing the word "DOSSIER" or "PATIENT_ID" should be treated as sensitive, you can configure a keyword match that flags and redacts anything following that token.

Writing a Dutch BSN rule

The Dutch BSN is nine digits with an 11-proof checksum. Presidio has a built-in NL_BSN recogniser, but if you need custom handling — say, you want to block rather than redact when a BSN appears in an outbound response — you can add a custom rule on top of the default recogniser.

The regex for the basic format is \b\d{9}\b. Add context words ("BSN", "burgerservicenummer", "sofinummer") to reduce false positives. In Guarrix's rule editor, you set the pattern, the entity label (NL_BSN_CUSTOM), and the action (BLOCK for outbound, REDACT for inbound).

Ordering matters

Rules apply in order. If you have a general EMAIL rule and a specific INTERNAL_EMAIL rule for your company's addresses, put the more specific rule first. Once a span is matched and actioned, it won't be matched again by a lower-priority rule.

Also: test your regex for catastrophic backtracking before you deploy it. A regex that performs O(n²) matching against long inputs will slow down every request that hits it. Guarrix validates patterns at configuration time and rejects known ReDoS patterns.

The operator options

• REPLACE: swap the matched span with a static string like "[REDACTED]" or "[POLICY_NUMBER]"
• MASK: replace characters with a mask character, keeping the length visible
• HASH: SHA-256 hash of the matched value — useful for pseudonymisation where you need to track without storing
• ENCRYPT: AES-256-GCM encryption — the matched value can be recovered with the key, useful for reversible anonymisation

Testing your rules

Guarrix's sandbox at /sandbox lets you test detection without authentication. Paste a text sample, run detection, and see exactly which spans are matched and what labels they carry. Use this before deploying a new rule to production — a misconfigured regex that over-matches will redact legitimate content and break your AI feature.