Industry compliance reference

This reference consolidates Arbitex’s security controls against industry-specific compliance requirements for 12 regulated verticals. For each vertical you will find the applicable regulatory frameworks, the DLP detectors that must or should be active, and a quick-start checklist. Use this document alongside the linked deep-dive guides — this page is a lookup and cross-reference, not a tutorial.

The 12 verticals covered are: Healthcare, Financial Services, Insurance, Government (Federal/State/Local), Defense/Intelligence, Energy/Utilities, Manufacturing, Telecommunications, Education, Legal/Law Firms, Pharmaceutical/Life Sciences, and Retail/E-Commerce.

---

Industry verticals overview

The table below gives a one-line summary of each vertical’s primary regulatory frameworks, data classification level, and risk profile. These are descriptions of the regulatory landscape each vertical operates in — they are not Arbitex configuration.

Vertical	Primary Frameworks	Data Classification	Risk Profile
Healthcare	HIPAA, HITECH, FDA 21 CFR Part 11	High (PHI)	Critical
Financial Services	SOX, PCI DSS 4.0, GLBA, FFIEC, Basel III	Critical (PII + Financial)	Critical
Insurance	NAIC Model Laws, SOX, state regulations	High (PHI + PII + Financial)	High
Government	FedRAMP, FISMA, NIST 800-53, StateRAMP	High–Critical (CUI)	Critical
Defense	CMMC 2.0, ITAR, EAR, NIST 800-171	Critical (CUI/ITAR)	Critical
Energy	NERC CIP, TSA Pipeline Security, ICS-CERT	High (OT/SCADA)	Critical
Manufacturing	NIST CSF, ISO 27001, CMMC (DoD supply chain)	Medium–High (IP)	High
Telecom	FCC regulations, CPNI rules, GDPR	High (CPNI)	High
Education	FERPA, COPPA, state privacy laws	Medium–High (student PII)	Medium
Legal	ABA Model Rules, attorney-client privilege	Critical (privileged)	Critical
Pharma	FDA 21 CFR Part 11, GxP, HIPAA	High (clinical trials)	Critical
Retail	PCI DSS 4.0, CCPA/CPRA, GDPR	Medium–High (PCI + PII)	Medium–High

Caution

Naming a framework here does not mean Arbitex ships an enforcement pack for it. This table describes the regulations that govern each vertical. Arbitex’s compliance packs are keyed by framework name, and the shipped set is narrower than this table — see What Arbitex actually ships below for the authoritative list before you plan a deployment.

Compliance packs provide a baseline; they do not guarantee regulatory compliance. Review your contractual obligations, engage your compliance officer, and validate configuration against current framework versions. Frameworks like PCI DSS 4.0 introduced requirements that differ significantly from PCI DSS 3.2.1.

What Arbitex actually ships

Arbitex seeds 13 compliance bundles, identified by regulatory framework name — not by vertical. Enable them per organization under Security & DLP → Policy Packs (/security/policy).

Shipped compliance bundle	Enforcement rules
PCI-DSS	Inline rule definitions
HIPAA	Inline rule definitions
GDPR	Inline rule definitions
GLBA, SOX, BSA/AML, CCPA, SEC Reg FD, FERPA	Seeded bundle, entity-mapping driven
EU AI Act, NIST AI RMF, ISO 42001	Seeded bundle, entity-mapping driven
Arbitex Cyber Threat Intel	Curated non-regulatory pack

Frameworks named in the vertical table but not in this list — including FedRAMP, FISMA, CMMC 2.0, NIST 800-53, NIST 800-171, StateRAMP, ITAR, EAR, NERC CIP, HITECH, FFIEC, Basel III, NAIC, ISO 27001, COPPA, GxP, FCC/CPNI, TSA Pipeline Security, ICS-CERT, and ABA Model Rules — have no Arbitex enforcement bundle. You can still build policy for them from individual detectors, but there is no packaged baseline to enable.

Danger

Defense and energy readers: Arbitex ships no ITAR, EAR, CMMC, or NERC CIP enforcement pack, and no ITAR, CUI, or export-control detector. Do not treat any configuration described on this page as satisfying an export-control or critical-infrastructure obligation. Controls for those regimes must be established outside Arbitex.

---

DLP detector cross-reference

The table below maps Arbitex DLP detectors to the 12 verticals. ✓ means the detector is required by at least one governing regulation in that vertical; ○ means it is strongly recommended for defense-in-depth even if not explicitly mandated; — means it is generally not applicable.

Enable all ✓ detectors before going to production in a given vertical. Enable ○ detectors unless you have a documented reason not to. Configure them under Security & DLP → Detectors (/security/detectors).

Every identifier in the Entity Type column below is a registered detector in the Arbitex DLP entity registry (arbitex-core, src/arbitex_core/dlp/registry/data/), which is the single source of truth for the detector inventory.

Detector	Entity Type	Healthcare	Financial	Insurance	Government	Defense	Energy	Manufacturing	Telecom	Education	Legal	Pharma	Retail
SSN	ssn	✓	✓	✓	✓	✓	○	○	✓	✓	✓	✓	✓
Credit card (PAN)	credit_card	○	✓	✓	○	—	—	—	○	—	—	—	✓
Bank account number	bank_account_number	—	✓	✓	○	—	—	—	○	—	—	—	○
Health information	health_info	✓	—	✓	○	—	—	—	—	○	○	✓	—
Medical record numbers	medical_record_number	✓	—	✓	—	—	—	—	—	—	○	✓	—
Student ID	student_id	—	—	—	○	—	—	—	—	✓	—	—	—
Academic transcript / score	transcript_score	—	—	—	○	—	—	—	—	✓	—	—	—
Email addresses	email	✓	✓	✓	✓	✓	○	○	✓	✓	✓	✓	✓
Telephone numbers	telephone	✓	✓	✓	✓	○	○	—	✓	✓	✓	✓	✓
Date of birth	date_of_birth	✓	✓	✓	✓	○	—	—	○	✓	✓	✓	✓
Driver’s license numbers	drivers_license	✓	✓	✓	✓	○	—	—	○	✓	✓	✓	✓
Passport numbers	passport	○	✓	✓	✓	✓	—	—	○	—	✓	○	✓
API key	api_key	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓
Bearer token	bearer_token	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓
Cryptographic private key	private_key	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓
Database connection string	connection_string	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓
Username/password combination	username_password_combo	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓

Tip

Arbitex has no single “credentials” detector. Credential coverage comes from the five separate detectors above — api_key, bearer_token, private_key, connection_string, and username_password_combo. Enable all five for every vertical: leaked credentials create immediate breach risk and are explicitly called out in SOC 2 Type II and ISO 27001 controls.

Caution

Detectors this page previously listed that do not exist. Arbitex ships no detector for ITAR markers, CUI markings, intellectual-property markers, attorney-client privilege markers, clinical trial identifiers, ICD-10/CPT codes, postal addresses, or source code. Earlier revisions of this page instructed enabling them. They are not available under any name, and no other detector covers their intent — geolocation detects latitude/longitude coordinate pairs, not postal addresses, and tlp_marking detects Traffic Light Protocol threat-intel markings, not classification or export-control markings. If your compliance programme depends on any of these, that gap must be closed outside Arbitex.

For configuration instructions, see DLP Pipeline Configuration. For detector accuracy benchmarks and tuning guidance, see DLP Accuracy.

---

Content categories

Arbitex content categories are safety and moderation categories, not use-case categories. The shipped set is:

drugs · extremism · foul_language · fraud · gambling · illegal_activity · self_harm · sexual_explicit · violence · weapons

Configure them under Security & DLP → Content Categories (/security/content-categories). They are defined in the Arbitex content registry (arbitex-core, src/arbitex_core/dlp/registry/data/content/).

Caution

This page previously published a different category taxonomy. Earlier revisions mapped twelve use-case categories — code_generation, data_analysis, creative_writing, customer_support, internal_comms, research, legal_review, medical_advice, financial_analysis, hr_operations, compliance_reporting, and executive_briefing — to per-vertical Block/Audit/Allow settings. None of those categories exists in Arbitex, and the two taxonomies do not overlap, so there is no equivalent setting to migrate to. Restricting AI use by task type is not something Arbitex content categories can express today; use group-scoped policy and model routing instead.

The regulatory concerns that motivated that mapping remain real, even though the controls described for them were not:

Caution

Healthcare — AI-generated clinical guidance: The HIPAA Privacy Rule at 45 CFR §164.508 requires individual authorization for certain uses and disclosures of PHI. AI-generated clinical guidance carries additional FDA Software as a Medical Device (SaMD) risk if it influences clinical decisions. Review the SaMD classification with your legal and clinical informatics teams before permitting clinical-advice workflows. Arbitex has no medical_advice category to block — this restriction has to be enforced through group policy, model routing, and organizational process.

Caution

Defense — controlled technical data: CMMC 2.0 Practice AC.3.021 and ITAR 22 CFR §120.10 prohibit export of controlled technical data via unauthorized channels. Arbitex provides no category, detector, or pack that identifies or blocks ITAR/EAR-controlled technical data. Restricting which use cases may reach an AI provider must be enforced outside Arbitex — through your export control officer’s approved-use process and through which groups are permitted gateway access at all.

For category configuration instructions, see Content Categories.

---

Vertical compliance considerations

The sections below describe the regulatory obligations that shape an Arbitex deployment in each vertical, and which Arbitex controls are actually available to help meet them.

Caution

These sections describe regulatory requirements, not a packaged Arbitex configuration. Earlier revisions of this page presented each vertical as a named policy pack (healthcare-hipaa, defense-cmmc, and ten others) with pack-specific DLP sensitivity defaults, token limits, and content-category restrictions. Those packs do not exist — see What Arbitex actually ships. Where a real Arbitex control maps to a requirement it is named explicitly below; where none does, the requirement is still listed so that you can plan for it elsewhere.

Healthcare

Governed by the HIPAA Security Rule (45 CFR Part 164, Subpart C), the HIPAA Privacy Rule, and HITECH Act breach notification requirements.

What you must control:

• Detection and redaction of protected health information in prompts and responses
• Medical record number handling
• Minimum necessary access — users should only reach PHI for the patient cohorts they are assigned
• Clinical trial participant data, where research workflows are in scope
• Breach notification evidence sufficient to scope an incident

Arbitex coverage: a HIPAA compliance bundle ships with inline enforcement rules. Relevant detectors: health_info, medical_record_number, ssn, email, telephone, date_of_birth. Minimum-necessary access is enforced through group scoping, not through a HIPAA-specific mechanism.

Not covered by Arbitex: ICD-10/CPT code detection and clinical trial identifier detection have no detector. Plan for these outside the platform if your programme depends on them.

Audit requirements: Every conversation should be logged. HIPAA sets a 6-year minimum retention for required documentation. Export audit events to your SIEM.

Model and provider restrictions: Cloud-provider models require a BAA to be in place before PHI-containing prompts are routed to them. If no BAA exists with a provider, restrict model routing to on-premises or Hybrid Outpost deployments.

---

Financial Services

Governed by SOX Sections 302/404, PCI DSS 4.0 (Requirements 3, 6, 7, 10, 12), the GLBA Safeguards Rule (16 CFR Part 314), and FFIEC IT Examination Handbook guidance.

What you must control:

• Primary account number (PAN) exposure
• Bank account and routing number exposure
• Material nonpublic information in internal communications
• Credential leakage into AI workflows
• Change and approval evidence for financial reporting workflows

Arbitex coverage: PCI-DSS (inline enforcement rules), SOX, GLBA, BSA/AML, and SEC Reg FD bundles ship. Relevant detectors: credit_card, payment_card_pan, cvv, bank_account_number, ssn, email, date_of_birth, and the five credential detectors.

Not covered by Arbitex: there is no source-code detector, and no dual-control/two-person approval gate on AI output. Both were previously documented here; neither exists. Arbitex also does not perform records retention, so it does not address SEC Rule 17a-4 broker-dealer recordkeeping — that obligation requires a WORM archive you provide.

Audit requirements: SOX evidence expectations run to 7 years; PCI DSS Requirement 10 requires 12 months active plus 12 months archived. Export to your SIEM promptly enough to support your incident response commitments.

Model and provider restrictions: Restrict to providers with SOC 2 Type II and PCI DSS attestations. For trading and banking core system integration, consider a Hybrid Outpost deployment.

---

Insurance

Governed by NAIC Model Law MDL-668 (Insurance Data Security Model Law), state insurance privacy regulations, SOX for publicly traded insurers, and overlapping HIPAA/HITECH requirements for health insurers.

What you must control:

• PHI, for health insurance lines
• Payment and bank account data in premium workflows
• Nonpublic personal information per GLBA (16 CFR §313)
• Separation between claims adjudication and unrelated policyholder data
• Actuarial and rate-setting material treated as confidential

Arbitex coverage: GLBA, SOX, and HIPAA bundles ship; there is no insurance-specific bundle. Relevant detectors: health_info, policy_number, claim_number, health_plan_member_id, credit_card, bank_account_number, ssn, email, telephone, date_of_birth, drivers_license. Line-of-business isolation is achieved with per-line groups.

Audit requirements: MDL-668 requires a written information security program. Audit logs must be available for state insurance department examination. Retain 5 years minimum.

Model and provider restrictions: Health insurance lines should follow the same BAA guidance as Healthcare above.

---

Pharma/Life Sciences

Governed by FDA 21 CFR Part 11 (electronic records and signatures), GxP (GMP/GLP/GCP), and overlapping HIPAA requirements for clinical trial data.

What you must control:

• Trial participant PII and PHI
• Electronic records used in regulated submissions, with attributable audit entries
• Drug formulation, synthesis route, and protocol confidentiality
• Change control over any configuration affecting a validated system

Arbitex coverage: the HIPAA bundle ships and applies to participant health data. There is no GxP or 21 CFR Part 11 bundle. Relevant detectors: health_info, medical_record_number, ssn, date_of_birth, rx_ndc, npi, dea_number.

Not covered by Arbitex: clinical trial identifier detection, intellectual-property markers, and a 21 CFR Part 11 electronic-signature binding on AI output all have no implementation. A Part 11 audit trail must be established in your validated systems, not assumed from Arbitex.

Audit requirements: A Part 11 audit trail must be computer-generated, time-stamped, and protected from modification. Retain 15 years for clinical trial records.

Model and provider restrictions: Validated computer systems under GxP require vendor qualification documentation. Request Arbitex’s vendor qualification package before deploying in a GxP environment. Hybrid Outpost deployment is strongly recommended to maintain system boundary control.

Danger

Read this before using the two sections in this tab. Arbitex ships no FedRAMP, FISMA, NIST 800-53, StateRAMP, CMMC, ITAR, EAR, or NIST 800-171 enforcement bundle, and no CUI, ITAR, or export-control detector. Nothing configurable in Arbitex identifies controlled unclassified information or export-controlled technical data. These sections describe obligations you must meet by other means; they do not describe an Arbitex capability.

Government

Governed by the FedRAMP Moderate/High baseline (NIST 800-53 Rev 5), FISMA, StateRAMP, and CUI handling requirements under Executive Order 13556 and 32 CFR Part 2002.

What you must control:

• CUI marking recognition and unauthorized disclosure prevention
• SSN and PII handling per the Privacy Act of 1974
• Access control per AC-3 (need to know) and AC-6 (least privilege)
• Session termination after inactivity (AC-11)
• Continuous monitoring and alert thresholds per NIST 800-137

Arbitex coverage: general DLP detectors (ssn, email, telephone, date_of_birth, passport, and the five credential detectors), group-scoped access control, and audit export. No CUI detection exists — the cui_marking identifier previously documented here is not implemented.

Audit requirements: NIST 800-53 AU controls require audit generation (AU-2), protection (AU-9), and review (AU-6). Minimum 3 years for FISMA; some agencies require longer. Export to an authorized SIEM inside the agency boundary.

Model and provider restrictions: FedRAMP Authorized AI providers only for cloud deployments. For the High baseline, consider a Hybrid Outpost deployment inside the agency authorization boundary. Consult your Authorizing Official before connecting to any AI provider not listed in your SSP.

---

Defense/Intelligence

Governed by CMMC 2.0 Level 2 and Level 3 practices, ITAR (22 CFR Parts 120–130), EAR (15 CFR Parts 730–774), and NIST SP 800-171 Rev 2.

What you must control:

• CUI transmission
• ITAR/EAR-controlled technical data
• Controlled technical information in engineering workflows
• Multi-factor authentication at the gateway (IA.3.083)
• Incident response and audit log protection (AU.2.042)

Arbitex coverage: general DLP detectors, group-scoped access control, audit export, and authentication policy. Nothing more. Arbitex cannot detect CUI, ITAR-controlled technical data, or export classification markings.

Danger

An unauthorized disclosure of ITAR-controlled technical data is a federal violation under 22 USC §2778, with civil penalties up to $1.32 million per violation and criminal penalties up to 20 years imprisonment. Arbitex provides no control that prevents this. Do not route ITAR-controlled technical data through any AI gateway, including Arbitex, without a control regime established and validated by your export control officer independently of this product.

Audit requirements: CMMC Practice AU.2.042 requires audit log protection. Export to an authorized SIEM inside your assessment boundary. Retain 3 years (DFARS 252.204-7012 requires 3-year retention of incident documentation). ITAR violations must be reported to the Directorate of Defense Trade Controls (DDTC).

Model and provider restrictions: Hybrid Outpost deployment for Level 3. For Level 2, US-hosted cloud models from providers with FedRAMP High authorization and DoD IL4/IL5 assessments may be permitted — confirm with your C3PAO.

---

Energy/Utilities

Governed by NERC CIP standards CIP-002 through CIP-014, TSA Pipeline Security Guidelines (2021), ICS-CERT advisories, and FERC Order 887.

What you must control:

• OT/SCADA system identifiers and network topology data
• Separation between IT and OT staff access
• BES cyber system information
• Physical security information
• Vendor and supply chain data (CIP-013)

Arbitex coverage: group-scoped access control (usable to separate IT and OT staff), general DLP detectors, and audit export with incident alerting. No OT, SCADA, ICS, or BES detector exists — Arbitex cannot recognize SCADA hostnames, device identifiers, PLC content, or DNP3/Modbus/IEC 61850 protocol material. IT/OT separation here is an access-control boundary, not content detection.

Audit requirements: NERC CIP-007-6 R4 requires security event logging. Retain 90 days locally and 3 years in long-term storage. FERC Order 887 requires notification within 1 hour for reportable incidents.

Model and provider restrictions: Hybrid Outpost deployment strongly recommended for OT environments. Air-gapped deployment is required if Arbitex sits inside an Electronic Security Perimeter as defined in NERC CIP-005.

---

Telecom

Governed by FCC CPNI rules (47 CFR Part 64, Subpart U), GDPR for EU operations, CCPA/CPRA, and the TCPA.

What you must control:

• CPNI — call records, service usage patterns, billing data
• Customer PII per GDPR Article 4
• Restriction of CPNI from flowing into marketing use cases
• Data minimization in responses returning customer records

Arbitex coverage: GDPR and CCPA bundles ship. Relevant detectors: telephone, email, ssn, date_of_birth, subscriber_group_id, ip_address. There is no CPNI bundle and no CPNI detector — CPNI scoping must be done through group policy and data handling process.

Audit requirements: FCC requires an annual CPNI certification filing. Retain 2 years minimum. GDPR Article 30 requires records of processing activities.

Model and provider restrictions: GDPR transfers to non-EEA countries require Standard Contractual Clauses or equivalent. Verify your provider’s data processing agreements before routing EU customer data to US-based models.

Manufacturing

Governed by NIST Cybersecurity Framework 2.0, ISO/IEC 27001:2022, and CMMC 2.0 Level 1 for DoD supply chain participants.

What you must control:

• Design files, CAD references, and manufacturing process detail
• Trade secrets
• Embedded systems and firmware source
• Stricter handling for external partner and vendor users
• CUI, if you are in the DoD supply chain

Arbitex coverage: group-scoped access control with per-group DLP sensitivity, general detectors, and audit export. No intellectual-property marker, trade-secret, source-code, CUI, or ITAR detector exists. The IP-protection capability previously described on this page is not implemented.

Audit requirements: ISO 27001 Annex A 5.33 requires preservation of evidence; NIST CSF DE.AE-3 requires continuous monitoring. Retain 3 years minimum.

Model and provider restrictions: No restrictions for standard manufacturing. DoD supply chain participants should read the Defense section above — including its limits.

---

Education

Governed by FERPA (20 USC §1232g; 34 CFR Part 99), COPPA (15 USC §6501 et seq.) for K-12, and state student privacy laws such as California SOPIPA and New York Education Law §2-d.

What you must control:

• Student records — names combined with grades, disciplinary records, financial aid, or enrollment status
• Dates of birth, for COPPA relevance
• Access restrictions for users under 18
• Directory information suppression
• Research data de-identification for IRB-approved studies

Arbitex coverage: a FERPA bundle ships. Relevant detectors: student_id, transcript_score, date_of_birth, ssn, email, telephone. Age-based restriction is achieved with groups.

Audit requirements: FERPA does not specify a minimum retention period; school records are typically retained per the NARA General Records Schedule. Retain 5–7 years. COPPA violations carry FTC civil penalties up to $50,120 per violation per day.

Model and provider restrictions: For K-12 and COPPA-covered deployments, confirm your provider has signed a COPPA-compliant school official data processing agreement before routing student data for users under 13.

---

Legal/Law Firms

Governed by ABA Model Rules of Professional Conduct (1.1, 1.4, 1.6), attorney-client privilege doctrine, work-product protection, and state bar ethics rules on technology competence.

What you must control:

• Privileged material reaching any model
• Work-product drafts
• Matter isolation between client engagements
• Conflict-of-interest exposure
• Opposing party information

Arbitex coverage: group-scoped access control, which is how matter isolation is implemented — one group per active matter. General PII detectors apply. There is no attorney-client privilege marker detector. The privilege_marker pattern previously documented here, including the claim that it reads document metadata, does not exist. Privilege designations are not detected by Arbitex; do not rely on the platform to catch a privileged document.

Audit requirements: ABA Model Rule 1.15 requires safekeeping of client property, which courts have interpreted to include digital records. Retain matter-related logs for the applicable statute of limitations — typically 6–10 years. Some state bars require client disclosure when AI tools are used; consult your state bar’s ethics guidance.

Model and provider restrictions: Attorney-client communications must remain confidential under Rule 1.6. Review provider terms and data processing agreements before routing privileged content. Consider a Hybrid Outpost deployment for highly sensitive litigation matters.

---

Retail/E-Commerce

Governed by PCI DSS 4.0 (Requirements 3, 4, 7, 10, 12), CCPA/CPRA (California Civil Code §1798.100 et seq.), GDPR for EU customers, and FTC Act Section 5.

What you must control:

• PAN exposure in prompts and responses
• Sensitive authentication data — PCI DSS Requirement 3.3 prohibits storage of CVV/CVC
• Cardholder data environment scoping
• Consumer PII as defined by CCPA
• Marketing opt-out and deletion-request handling

Arbitex coverage: PCI-DSS (inline enforcement rules) and CCPA and GDPR bundles ship. Relevant detectors: credit_card, payment_card_pan, cvv, magstripe, pci_data, bank_account_number, ssn, email, telephone, date_of_birth, drivers_license, ip_address. CDE scoping is done with groups.

Audit requirements: PCI DSS Requirement 10 mandates audit logging of all access to system components and cardholder data. Retain 12 months with 3 months immediately available. CCPA requires records of access and deletion requests for 24 months. GDPR Article 5(2) requires demonstrable compliance records.

Model and provider restrictions: PCI DSS Requirement 12.8 requires management of service providers. Confirm your provider is in your PCI DSS scope or holds its own AOC. Scope your CDE carefully — if Arbitex is deployed within CDE scope, its infrastructure must be included in your assessment.

---

Quick-start guides

Use the checklist for your vertical to establish a baseline. Complete all steps before routing production traffic through Arbitex.

Caution

These checklists configure Arbitex. They do not by themselves make a deployment compliant with the frameworks named, and for several verticals Arbitex provides no framework-specific control at all. Read the vertical’s entry under Vertical compliance considerations — especially the “not covered by Arbitex” notes — before treating a completed checklist as evidence of anything.

Healthcare

Healthcare quick-start

1. Enable the HIPAA compliance bundle. In the admin portal, go to Security & DLP → Policy Packs (/security/policy) and enable HIPAA for your organization. Confirm the bundle rules load without conflicting with existing custom policy.
2. Enable detectors. Under Security & DLP → Detectors (/security/detectors), enable health_info, medical_record_number, ssn, email, telephone, date_of_birth, plus api_key, bearer_token, private_key, connection_string, and username_password_combo. See DLP Pipeline Configuration.
3. Scope access by group. Create groups matching your patient cohort or department boundaries so that minimum-necessary access is enforced by group membership.
4. Configure audit log export. Enable 6-year retention and export audit events to your SIEM. See Audit Log Management.
5. Verify BAA coverage. Confirm a signed BAA is in place with Arbitex and with every AI provider you route PHI-containing prompts to. If a BAA is missing, restrict model routing to a Hybrid Outpost deployment.
6. Review compliance reporting. Check Security & DLP → Compliance Reports (/security/compliance-reports) and the Compliance Dashboard (/security/compliance-dashboard) for the evidence views available to you.
7. Test with de-identified sample data. Run a test suite with synthetic PHI — never real patient data — to confirm detection and redaction behave as expected. Use the Outpost Policy Simulator for policy validation.
8. Review and tune. After two weeks of production traffic, review false positive and false negative rates in DLP Accuracy and adjust Tier 3 confidence thresholds if needed.

Financial

Financial services quick-start

1. Enable the relevant compliance bundles. Under Security & DLP → Policy Packs, enable PCI-DSS, SOX, GLBA, and — where applicable — BSA/AML and SEC Reg FD.
2. Enable detectors. credit_card, payment_card_pan, cvv, bank_account_number, ssn, email, date_of_birth, and the five credential detectors.
3. Scope access by group. Use groups to enforce GLBA need-to-know boundaries between business functions.
4. Configure audit log export. Enable 7-year retention for SOX evidence. Export to your SIEM.
5. Review compliance reporting. Use Compliance Reports (/security/compliance-reports) for SOX and PCI DSS evidence, and Monitoring & Reporting → DLP Activity (/monitoring/dlp-activity) for detection activity.
6. Verify provider attestations. Confirm every AI provider in your routing rules has a current SOC 2 Type II report and PCI DSS AOC. Remove any provider that does not.
7. Test with masked sample data. Use synthetic financial data to test PAN handling and bank account detection.
8. Review and tune. Review false positive rates after 30 days with your legal team.

Insurance

Insurance quick-start

1. Enable the relevant compliance bundles. There is no insurance-specific bundle. Enable GLBA, SOX (publicly traded insurers), and HIPAA for health insurance lines.
2. Enable detectors. health_info (health lines), policy_number, claim_number, health_plan_member_id, credit_card, bank_account_number, ssn, email, telephone, date_of_birth, drivers_license, and the five credential detectors.
3. Map groups to business lines. Create separate groups for health, P&C, and life lines. Apply line-specific DLP sensitivity overrides using group policy — this is what enforces claims/underwriting isolation.
4. Configure audit log export. Enable 5-year retention minimum. Ensure logs are accessible for state insurance department examination requests.
5. Review compliance reporting. Use Compliance Reports (/security/compliance-reports) to assemble evidence for your written information security program under MDL-668.
6. Test claims and underwriting workflows. Run test cases for claims adjudication and underwriting prompts to confirm group isolation works.
7. Review and tune. Review after your first regulatory exam cycle and adjust based on examiner findings.

Government

Government quick-start

Danger

Arbitex ships no FedRAMP, FISMA, NIST 800-53, or StateRAMP bundle and no CUI detector. This checklist configures general DLP and access control only. It does not implement CUI handling.

1. Enable detectors. ssn, email, telephone, date_of_birth, passport, and the five credential detectors.
2. Scope access by group. Implement AC-3 need-to-know and AC-6 least privilege through group membership and model routing rules.
3. Configure audit log export. Enable 3-year minimum retention. Export to your agency-authorized SIEM within the authorization boundary. Confirm AU-9 audit log protection controls are in place in the receiving system.
4. Document in your SSP. Add Arbitex as a system component. Document the boundary, data flows, and inherited controls.
5. Document the CUI gap explicitly. Your SSP must record that automated CUI marking detection is not provided by Arbitex, and identify the compensating control that handles it.
6. Obtain AO approval. Do not route agency data through Arbitex until your Authorizing Official has reviewed the control implementation and issued an ATO or interconnection agreement.
7. Review and tune. Continuous monitoring per NIST 800-137 — review monthly and after any significant system change.

Defense

Defense quick-start

Danger

Arbitex ships no CMMC, ITAR, EAR, or NIST 800-171 bundle, and no CUI, ITAR, or export-control detector. There is no configuration in Arbitex that detects or blocks controlled technical data. Do not use this checklist as an export-control measure.

1. Enable detectors. The general detectors listed for Defense in the cross-reference table. Note that none of them recognizes CUI or ITAR-controlled technical data.
2. Restrict gateway access by group. Because content-based export controls are unavailable, the meaningful control is who may reach the gateway at all. Restrict access to cleared personnel groups.
3. Configure audit log export. Enable 3-year retention. Export to your CMMC-scoped SIEM. Ensure tamper-evident log protection in the receiving system (CMMC Practice AU.2.042).
4. Enforce multi-factor authentication at the gateway (IA.3.083) through auth policy.
5. Engage your C3PAO. Discuss the Arbitex deployment with your CMMC Third-Party Assessment Organization to confirm assessment scope — and disclose that no ITAR/CUI content control is present.
6. Review export controls with your export control officer. Have them review every AI provider in the model routing policy and establish the control regime for controlled technical data outside Arbitex.
7. Review and tune. Monthly review. Any policy change requires documented change control review.

Energy

Energy/utilities quick-start

Danger

Arbitex ships no NERC CIP bundle and no OT, SCADA, ICS, or BES detector. IT/OT separation below is an access-control boundary, not content detection — Arbitex cannot recognize SCADA hostnames, device identifiers, or OT protocol content.

1. Enable detectors. ip_address, email, telephone, and the five credential detectors.
2. Separate IT and OT groups. Create distinct groups for IT and OT staff and apply OT-specific DLP sensitivity to the OT group. This is the primary available control.
3. Configure audit log export. Enable 3-year long-term retention with 90-day local retention, per CIP-007-6 R4.
4. Configure alerting. Use Monitoring & Reporting → Alerts to route DLP events to your incident process, supporting FERC Order 887 1-hour notification.
5. Assess the ESP boundary. If Arbitex is deployed within a NERC CIP Electronic Security Perimeter, include it in your CIP-005 assessment. Air-gapped or Hybrid Outpost deployment is required inside an ESP.
6. Record the OT detection gap in your CIP compliance documentation, with the compensating control that covers it.
7. Review and tune. Run a full audit export and review with your compliance team 60 days before the annual audit window.

Telecom

Telecom quick-start

1. Enable the relevant compliance bundles. GDPR and CCPA. There is no CPNI bundle.
2. Enable detectors. telephone, email, ssn, date_of_birth, subscriber_group_id, ip_address, and the five credential detectors.
3. Scope CPNI by group. CPNI is not detectable as content. Enforce the marketing-use restriction by keeping CPNI-handling groups separate from marketing groups and restricting which groups may reach which models.
4. Configure audit log export. Enable 2-year retention. For GDPR, ensure the SIEM is within the EU data boundary for EU customer data.
5. Review GDPR data transfers. Confirm Standard Contractual Clauses are in place for any AI provider receiving EU customer data. Document in your Article 30 records.
6. Assemble the FCC certification evidence. Use Compliance Reports (/security/compliance-reports) and audit export; there is no dedicated CPNI usage report.
7. Test with synthetic customer data. Run test cases for customer support and network management workflows.
8. Review and tune. Review after each annual FCC CPNI filing cycle.

Manufacturing

Manufacturing quick-start

Caution

Arbitex ships no intellectual-property marker, trade-secret, source-code, CUI, or ITAR detector. The IP-protection workflow previously described here is not implemented.

1. Enable detectors. email, ip_address, and the five credential detectors.
2. Configure vendor group controls. Create a restricted group for external vendor and partner users with higher DLP sensitivity than internal groups. With no IP detector available, group scoping is the control that does the work.
3. Configure audit log export. Enable 3-year retention. Export to your SIEM per ISO 27001 Annex A 5.33 evidence requirements.
4. Review compliance reporting. Use Compliance Reports (/security/compliance-reports) and Usage & throttle (/monitoring/usage) for ISO 27001 management review evidence.
5. Record the IP detection gap in your ISO 27001 risk treatment plan.
6. If you are in the DoD supply chain, read the Defense section — including its limits — before handling CUI.
7. Review and tune. Annual ISO 27001 surveillance audit — ensure Arbitex is in your audit scope and evidence package.

Education

Education quick-start

1. Enable the FERPA compliance bundle under Security & DLP → Policy Packs.
2. Enable detectors. student_id, transcript_score, date_of_birth, ssn, email, telephone.
3. Configure student user groups. Create separate groups for students under 18, students over 18, and staff. Apply minor-protection restrictions to the under-18 group — age-based restriction is implemented with groups.
4. Configure audit log export. Enable 5-year retention. Ensure logs are accessible for FERPA compliance review requests.
5. Obtain COPPA service agreements. For K-12, confirm your AI provider has signed a COPPA-compliant school official data processing agreement before routing data for students under 13.
6. Test student record isolation. Verify that a student cannot query another student’s records through the AI interface, using synthetic student data.
7. Review and tune. Annual review aligned with your institution’s FERPA compliance review cycle. Update after state privacy law changes — these change frequently.

Legal

Legal quick-start

Danger

Arbitex ships no attorney-client privilege detector. Privilege designations in text or document metadata are not detected. Do not rely on the platform to catch a privileged document — matter isolation by group is the available control.

1. Set matter isolation groups. Create a separate group for each active client matter. Assign attorneys and staff only to the matters they work on. This is the primary control.
2. Enable detectors. ssn, email, telephone, date_of_birth, and the five credential detectors.
3. Configure audit log export. Enable 7-year retention, adjusted to your jurisdiction’s statute of limitations. Export to a matter management system or secure legal hold repository.
4. Establish a manual privilege-handling process. Because privilege markers are not detected, define and train an intake process that keeps privileged material out of AI workflows in the first place.
5. Review AI disclosure obligations. Consult your state bar’s ethics opinions on AI tool use. Some bars require client disclosure. Update engagement letter templates if required.
6. Review and tune. Annual ethics compliance review.

Pharma

Pharma/life sciences quick-start

Caution

Arbitex ships no GxP or 21 CFR Part 11 bundle, and no clinical trial identifier detector. A Part 11 audit trail must be established in your validated systems.

1. Enable the HIPAA compliance bundle for participant health data.
2. Enable detectors. health_info, medical_record_number, ssn, date_of_birth, rx_ndc, npi, dea_number, and the five credential detectors.
3. Request the vendor qualification package. Obtain Arbitex’s IQ/OQ/PQ documentation before proceeding with GxP workflows.
4. Scope trial data by group. Restrict trial-specific data to groups matching trial staffing.
5. Establish validated system change control. Any change to Arbitex configuration in a GxP environment must go through your change control process — CAPA entry, impact assessment, validation testing, QA approval — before activation.
6. Configure audit log export. Enable 15-year retention for clinical trial records. Export to your validated document management system or audit vault.
7. Test with synthetic trial data. Use synthetic participant identifiers and protocol references, never real trial data.
8. Review and tune. Validation review after any system change. Include Arbitex in your annual quality system review.

Retail

Retail/e-commerce quick-start

1. Enable the relevant compliance bundles. PCI-DSS, CCPA, and GDPR for EU customers.
2. Enable detectors. credit_card, payment_card_pan, cvv, magstripe, pci_data, bank_account_number, ssn, email, telephone, date_of_birth, drivers_license, ip_address, and the five credential detectors.
3. Define CDE scope. Identify which groups interact with cardholder data and apply Critical DLP sensitivity to those groups. Groups outside CDE scope can use a lower sensitivity.
4. Configure audit log export. Enable 12-month active plus 12-month archived retention (PCI DSS Requirement 10.7). Export to your SIEM.
5. Verify provider PCI compliance. Confirm every AI provider in your routing rules is in your PCI DSS scope or holds its own AOC. Remove any that is not from routing rules that may receive cardholder data.
6. Review compliance reporting. Use Compliance Reports (/security/compliance-reports) for PCI DSS and CCPA evidence.
7. Test PAN handling. Submit test prompts containing synthetic PANs — use Luhn-valid test numbers, never real PANs — to confirm detection and CVV handling.
8. Review and tune. Annual PCI DSS assessment cycle — ensure Arbitex is in your QSA scope. Update CCPA data processing records after any change to consumer data flows.

---

Compliance reporting

Arbitex surfaces several views that support regulatory evidence gathering. The table below cross-references them to their primary framework use cases.

Surface	Location	Frameworks Served	Typical Use
DLP Activity	Monitoring & Reporting → DLP Activity (/monitoring/dlp-activity)	HIPAA, PCI DSS, GDPR, CCPA	Breach notification evidence; incident log for regulator review
Audit log	Monitoring & Reporting → Audit log (/monitoring/audit)	All frameworks	Primary evidence for compliance audits; timestamped, user-attributed activity log. Also the source for policy-change evidence
Compliance Reports	Security & DLP → Compliance Reports (/security/compliance-reports)	Bundles you have enabled	Framework-scoped evidence export
Compliance Dashboard	Security & DLP → Compliance Dashboard (/security/compliance-dashboard)	Bundles you have enabled	Posture overview
Compliance Matrix	Security & DLP → Compliance Matrix (/security/compliance-matrix)	Bundles you have enabled	Control-to-framework mapping
Usage & throttle	Monitoring & Reporting → Usage & throttle (/monitoring/usage)	SOX, FFIEC, ISO 27001	Cost governance; demonstrate controls over AI spend; management review evidence
SIEM Connectors	System → SIEM Connectors (/system/siem)	All frameworks	Forwarding audit evidence to your SIEM

Caution

Compliance reporting is scoped to the bundles you have actually enabled. There is no dedicated PHI Access Report, CPNI Usage Report, or CUI Handling Report — earlier revisions of this page listed all three, along with a top-level Reports section that does not exist in the admin portal. For frameworks with no Arbitex bundle (FedRAMP, CMMC, NERC CIP, FCC/CPNI and the others listed above), assemble evidence from the audit log export rather than expecting a framework-specific report.

Tip

For SIEM-based compliance evidence, note that Arbitex tags bundle-rule violations in the audit log with a compliance_bundle tag identifying the bundle that fired. Filter on it to build per-framework SIEM dashboards. See SIEM Integration for Splunk, Microsoft Sentinel, and Elastic configurations.

Audit log as primary evidence. The Arbitex audit log satisfies the fundamental evidentiary requirement of most frameworks: a tamper-evident, user-attributed, timestamped record of all access to sensitive data. When exporting for audit evidence, always include the request_id, user_id, group_id, dlp_events, policy_action, and model_provider fields. These fields give auditors the chain of custody they require.

DLP activity for breach notification. Under HIPAA §13402, GDPR Article 33, and state breach notification laws, you may need to demonstrate the scope of a breach within tight time windows (72 hours for GDPR). The DLP Activity view gives you a filtered view of DLP blocks and detections in a time range, with the affected user, the detected entity type, and the action taken. This is your first data source in a breach investigation.

Usage analytics for cost governance. SOX Section 404 internal controls and FFIEC guidance both require controls over operational risk, which regulators increasingly interpret to include AI system cost and usage governance. The Usage & throttle view provides per-group, per-model, and per-user token consumption data that you can use to demonstrate budgetary controls.

---

See also

• Compliance Frameworks — Deep-dive guides for HIPAA, PCI DSS, FedRAMP, CMMC, GDPR, and more
• DLP Pipeline Configuration — Step-by-step DLP pattern activation and sensitivity tuning
• DLP Regulatory Patterns — Detailed pattern specifications and detection accuracy data
• Content Categories — Full content category system documentation and custom category creation
• Policy Configuration — Policy pack activation, custom policy authoring, and group policy assignment
• Audit Log Management — Retention configuration, export formats, and SIEM integration
• Outpost Policy Simulator — Pre-production policy validation tool
• Portal Search API — Programmatic access to compliance reports and audit events