Compliance Mapping Guide

This guide is for compliance officers, auditors, and GRC teams performing gap analysis or preparing for regulatory audits. It presents Arbitex capabilities as a cross-framework control matrix — showing which controls apply to which frameworks simultaneously — and provides framework-by-framework mappings with evidence artifacts and shared responsibility boundaries.

How this page differs from related pages:

Compliance Frameworks Reference — describes what each bundle detects and enforces, framework by framework
Compliance Frameworks guide — operational how-to for activating bundles and configuring your policy chain
This page — cross-framework matrix for gap analysis; framework-specific regulatory mappings with audit evidence and customer responsibilities

Control Matrix

The following table shows which Arbitex capabilities address requirements in each of the 8 supported regulatory frameworks. Use this matrix to identify which capabilities are relevant to your specific obligations and to scope a gap analysis.

Legend: ✓ = addresses one or more requirements in this framework | — = not applicable or organizational

Arbitex Capability	PCI-DSS	HIPAA	GDPR	GLBA	SOX	BSA/AML	CCPA	SEC Reg FD
DLP inline detection	✓	✓	✓	✓	✓	✓	✓	✓
Policy Engine enforcement	✓	✓	✓	✓	✓	✓	✓	✓
Compliance Bundles	✓	✓	✓	✓	✓	✓	✓	✓
Tamper-evident audit trail	✓	✓	✓	✓	✓	✓	✓	✓
SIEM export (OCSF v1.1)	✓	✓	✓	✓	✓	✓	✓	✓
Model Risk Management	—	—	—	✓	✓	✓	—	—
Credential Intelligence (CredInt)	✓	✓	✓	✓	—	—	✓	—
Human-in-the-loop governance	—	✓	✓	✓	✓	✓	✓	—
Data retention controls	✓	✓	✓	✓	✓	✓	✓	✓
Encryption in transit (mTLS, TLS 1.2+)	✓	✓	✓	✓	✓	—	✓	—
Access controls (RBAC, group-based policies)	✓	✓	✓	✓	✓	✓	✓	✓
Audit log export (JSONL, CSV, JSON)	✓	✓	✓	✓	✓	✓	✓	✓

Capability descriptions

DLP inline detection — Real-time scanning of every AI request and response in the DLP pipeline before policy evaluation. Each Compliance Bundle activates a set of framework-specific entity types (PANs, PHI identifiers, GDPR special categories, etc.). Detection runs on every request with no sampling.

Policy Engine enforcement — Five terminal actions (BLOCK, CANCEL, REDACT, ALLOW_WITH_OVERRIDE, PROMPT) applied when bundle or custom rules match. Every action produces a security_finding audit log entry with the framework reference, rule ID, pack ID, and matched category.

Compliance Bundles — Pre-built policy packs mapped to regulatory frameworks. Each bundle contains detection patterns and policy rules that enforce atomically when the bundle is active in your policy chain. Bundles are read-only — rules cannot be suppressed or modified.

Tamper-evident audit trail — HMAC-SHA256 chain where each audit entry includes the HMAC of the preceding entry. Any modification, deletion, or reordering of entries breaks the chain and is reported by the verification API. All platform events are logged: chat completions, policy decisions, DLP triggers, authentication, and administrative changes.

SIEM export (OCSF v1.1) — Enforcement events export in Open Cybersecurity Schema Framework v1.1 format. Bundle enforcement actions map to OCSF class 2001 (Security Finding). Authentication events export as class 3002. Administrative changes export as class 3001. SIEM dashboards can filter by metadata.framework_reference to scope views to a specific regulation.

Model Risk Management — Model Registry with OCC SR 11-7 aligned risk tiers (critical, high, medium, low), structured validation lifecycle (unclassified → under_review → approved/conditional/deprecated), immutable approval log, and Policy Engine integration via model_risk_tier condition. Relevant for financial institution regulators (GLBA, SOX, BSA/AML) with SR 11-7 obligations.

Credential Intelligence (CredInt) — Bloom filter detection of leaked or known-bad credentials appearing in prompts. Applicable where access controls and credential hygiene are regulatory requirements.

Human-in-the-loop governance — PROMPT and ALLOW_WITH_OVERRIDE actions route requests through approval workflows before proceeding. The ALLOW_WITH_OVERRIDE action creates an accountable exception record. The PROMPT action interposes a governance challenge before the request is processed.

Data retention controls — 90-day active retention + 2-year archive in Azure Log Analytics. For frameworks requiring longer retention (BSA/AML: 5 years; SEC 17a-4: 3–6 years), configure your SIEM retention accordingly.

Encryption in transit — TLS 1.2+ on all external connections; mTLS on internal service-to-service connections and Outpost tunnels. Application-layer Fernet encryption for stored credentials and configurations.

Access controls (RBAC, group-based policies) — Role-based access control at the API layer (admin, org_admin, audit_viewer, user roles). Group-based policy rules allow different enforcement tiers for different user populations. SAML SSO and MFA enforced per org policy.

Audit log export — Portal export (GET /v1/orgs/{org_id}/audit/export) returns CSV or JSON with filters for action type, user, time range, and severity. Compliance export API (POST /api/v1/admin/audit/export) produces signed JSON packages with HMAC chain verification for auditor submission. Both support filtering by date range and event type.

Framework-by-Framework Mapping

PCI-DSS

Standard: Payment Card Industry Data Security Standard v4.0 Regulatory body: PCI Security Standards Council Scope: Any system that stores, processes, or transmits payment card data. An AI Gateway proxying employee or customer conversations creates risk of cardholder data (PANs, CVVs) appearing in prompts.

Requirements addressed by Arbitex

PCI-DSS Requirement	Arbitex controls	Evidence artifacts
Req 3 — Protect stored cardholder data	BLOCK prevents PAN transmission through the Gateway; matched category logged, content not retained	`security_finding` audit entries with `framework_reference: "PCI-DSS Requirement 3"`
Req 3.4 — Render PAN unreadable	BLOCK prevents PAN from reaching downstream model or response; audit log references `PCI-DSS Requirement 3.4`	SIEM events filtered by `metadata.framework_reference = "PCI-DSS Requirement 3.4"`
Req 6.4 — Protect web-facing applications	Cloudflare WAF with OWASP ruleset + custom AI proxy rules; mTLS on all service connections	Network architecture documentation (customer-side); Arbitex infrastructure control documentation — no third-party attestation exists (see Certification row below)
Req 8 — Identify users and authenticate	API key authentication + RS256 JWT; SAML SSO; MFA enforced per org policy	Authentication audit entries (OCSF class 3002); user provisioning export
Req 8.6 — MFA for all access	MFA policy enforced at authentication layer; FIDO2/TOTP/SMS supported	Authentication audit trail; MFA enrollment status export
Req 10 — Track and monitor all access	Tamper-evident HMAC-SHA256 chained audit trail; all API requests logged with org, user, action, and timestamp	Full audit log export; HMAC chain verification report (`POST /api/v1/admin/audit/verify`)
Req 10.3.2 — Protect audit logs	90-day active + 2-year archive; HMAC chain detects modification; SIEM export for long-term retention	Chain verification API; Azure Log Analytics immutable archive
Req 10.5 — Retain audit logs minimum 12 months	90-day Arbitex retention; SIEM integration required for full 12-month retention	Compliance export with date-range filter; SIEM retention configuration is customer responsibility

Customer responsibilities (not covered by Arbitex)

Full PCI-DSS cardholder data environment (CDE) scoping and segmentation
Penetration testing and vulnerability scanning of your infrastructure
Physical security controls
Third-party service provider attestations beyond Arbitex
Bring Your Own Key (BYOK) for customer-managed encryption (planned feature)

HIPAA

Standard: Health Insurance Portability and Accountability Act — Privacy Rule + Security Rule Regulatory body: U.S. Department of Health and Human Services Scope: Covered entities (healthcare providers, health plans, clearinghouses) and business associates. AI Gateways used by healthcare organizations create risk of Protected Health Information (PHI) appearing in prompts or completions.

Requirements addressed by Arbitex

HIPAA Rule / CFR Reference	Arbitex controls	Evidence artifacts
45 CFR § 164.312 — Technical safeguards	BLOCK prevents PHI transmission; enforcement logged with framework reference; TLS in transit	`security_finding` entries with PHI category labels; TLS configuration
45 CFR § 164.502 — Uses and disclosures	BLOCK prevents PHI disclosure to model providers or users outside permitted use	Audit entries showing blocked PHI disclosures; group-based policy rule definitions
45 CFR § 164.312(b) — Audit controls	Complete audit trail of all requests; PHI detections logged by category, content not retained	Full audit log export; compliance export with `framework=HIPAA` filter
45 CFR § 164.312(e)(1) — Transmission security	TLS 1.2+ everywhere; mTLS on internal services and Outpost connections	Network configuration attestation
Minimum Necessary standard	Only matched category retained in audit, not PHI content itself	Audit log schema confirming no prompt/completion content stored
45 CFR § 164.312(d) — Authentication	RBAC with org_admin, audit_viewer, user roles; SAML SSO; MFA per policy	Authentication audit trail; user access export
Human-in-the-loop for PHI workflows	`PROMPT` and `ALLOW_WITH_OVERRIDE` actions route PHI-adjacent requests through approval workflows	Override audit records with user attestation and timestamp

Customer responsibilities

Business Associate Agreement (BAA) — available from the Arbitex account team; signing is customer-initiated
Workforce training and sanction policies
Physical access controls to covered entity systems
Patient rights request workflows (right of access, amendment)
Breach notification procedures under the HIPAA Breach Notification Rule
BYOK for PHI data encryption (planned feature)

Standard: EU General Data Protection Regulation (Regulation 2016/679) Regulatory body: EU Data Protection Authorities (supervisory authorities per member state) Scope: Processing of personal data of EU data subjects, regardless of where the processing organization is located. AI systems processing EU resident data through a Gateway are in scope.

Requirements addressed by Arbitex

GDPR Article	Arbitex controls	Evidence artifacts
Art. 5(1)(c) — Data minimization	Policy Engine enforces purpose limitation at AI layer; REDACT removes personal data before model sees it	Policy rule definitions with purpose-limited conditions; REDACT action audit entries
Art. 5(1)(e) — Storage limitation	Arbitex does not retain prompt/completion content; audit entries log category, not content	Audit log schema documentation confirming no content retention
Art. 5(1)(f) — Integrity and confidentiality	Encryption in transit (TLS 1.2+); HMAC-chained audit logs; BLOCK prevents unauthorized disclosure	Chain verification report; TLS attestation
Art. 5(2) — Accountability	Audit trail with per-request logging; SIEM export provides records of processing activity	Compliance export with `framework=GDPR` filter; OCSF events in SIEM
Art. 25 — Data protection by design	DLP pipeline runs before model invocation; policy controls enforced before data leaves tenant boundary	Bundle activation records; DLP pipeline architecture documentation
Art. 30 — Records of processing	Audit trail captures processing activities per user, timestamp, action, and data category	Full audit log export; compliance export by date range
Art. 32 — Security of processing	TLS everywhere; application-layer Fernet encryption; private endpoints; HMAC audit integrity	Security architecture documentation; HMAC chain verification
Art. 9 — Special category data	GDPR bundle `is_required=true` rules for special categories (health, biometric, racial/ethnic, political, genetic) cannot be individually disabled while bundle is active	Bundle activation record; non-suppressible rule configuration
Art. 22 — Automated decision-making	`PROMPT` and `ALLOW_WITH_OVERRIDE` actions interpose human review for automated decisions affecting individuals	Override and approval audit records

Customer responsibilities

Legal basis determination for each processing activity
Privacy policy and notice requirements
Data subject rights requests (right of access, erasure, portability, rectification)
Data Protection Impact Assessments (DPIAs)
Data Protection Officer (DPO) designation where required
Standard Contractual Clauses and transfer impact assessments for international data flows
Breach notification to supervisory authorities under Art. 33
BYOK / data sovereignty controls (planned feature)

GLBA

Standard: Gramm-Leach-Bliley Act — Financial Privacy Rule + Safeguards Rule (16 CFR Part 314) Regulatory body: FTC; federal banking agencies (OCC, FDIC, Federal Reserve) Scope: Financial institutions — banks, lenders, insurance companies, investment advisors. The Safeguards Rule requires a written information security program protecting customer nonpublic personal information (NPI).

Requirements addressed by Arbitex

GLBA Safeguards Rule Section	Arbitex controls	Evidence artifacts
§314.4(c) — Risk assessment	Audit trail provides AI system risk signal; detected NPI transmission events logged for risk review	Compliance export with `framework=GLBA` filter; DLP trigger events
§314.4(d) — Safeguards: access controls	RBAC at API layer; group-based model access controls; API key scoping	User and group export; policy chain configuration export
§314.4(d) — Safeguards: encryption	TLS in transit; Fernet application-layer encryption for stored credentials and configs	Security architecture documentation
§314.4(d) — Safeguards: NPI transmission prevention	BLOCK action prevents NPI transmission; detection patterns cover GLBA NPI categories (account numbers, routing numbers, SSNs in financial context)	Audit entries with `framework_reference: "GLBA Safeguards Rule §314.4(d)"`
§314.4(h) — Monitor, test, respond	SIEM integration exports GLBA-relevant enforcement events in OCSF format	OCSF export filtered by `metadata.framework_reference`; SIEM alert configurations
SR 11-7 Model Risk Management	Model Registry with risk tiers, validation lifecycle, immutable approval log; `model_risk_tier` policy conditions	Model inventory export (CSV/JSON); approval log for status transitions

Customer responsibilities

Designation of a qualified individual responsible for the information security program (§314.4(b))
Annual board/management reporting on the information security program
Service provider oversight and contractual provisions (§314.4(i))
Employee training program
Incident response plan with customer notification procedures
Penetration testing and vulnerability assessments

SOX

Standard: Sarbanes-Oxley Act — Sections 302 and 404 Regulatory body: SEC; PCAOB Scope: Public companies and subsidiaries. Section 404 requires management assessment of internal controls over financial reporting (ICFR). AI systems used by finance teams are in scope when processing or generating financial reporting data.

Requirements addressed by Arbitex

SOX Control Area	Arbitex controls	Evidence artifacts
ICFR — IT general controls: logical access	API key auth + RS256 JWT + SAML SSO; RBAC enforced at middleware layer; group-based model access	User provisioning export; group membership export; authentication audit trail
ICFR — IT general controls: audit trail	Tamper-evident HMAC-chained audit trail; all AI interactions logged with user ID, admin ID, and timestamp	Full audit log export; chain verification report
ICFR — Change management	Audit log captures all policy chain changes with admin ID, timestamp, and before/after state	Administrative change events (OCSF class 3001); policy configuration audit history
ICFR — Monitoring	SIEM export of enforcement events; continuous monitoring of AI system behavior for anomalies	OCSF export; SIEM dashboard; alert configuration
Access controls for financial data	Policy Engine restricts model access and financial data transmission by group; group rules vary enforcement by user classification	Group policy rule definitions; enforcement audit entries
SR 11-7 Model Risk Management	Model Registry governs which AI models are approved for use in financial workflows; validation lifecycle with immutable approval log	Model inventory export; approval log; `model_risk_tier` policy rules

Customer responsibilities

External auditor engagement (management and auditor assessments under §404)
CEO/CFO certifications under §302
Disclosure controls and procedures governance
Whistleblower protections and anonymous reporting mechanisms
Full financial system access control review (Arbitex covers only the AI Gateway layer)

BSA/AML

Standard: Bank Secrecy Act / Anti-Money Laundering (31 U.S.C. § 5311 et seq.) Regulatory body: FinCEN; federal banking agencies; FINRA (for broker-dealers) Scope: Financial institutions, money services businesses, broker-dealers. AI systems used in customer communications or transaction processing are in scope for suspicious activity monitoring obligations.

Requirements addressed by Arbitex

BSA/AML Requirement	Arbitex controls	Evidence artifacts
Suspicious Activity Reporting (31 U.S.C. § 5318(g))	Suspicious patterns in AI interactions logged with matched category and rule reference; exported to SIEM for compliance team review	SIEM events filtered by `metadata.framework_reference`; compliance export with `framework=BSA_AML` filter
Customer Identification Program (CIP)	Sensitive identification data in prompts triggers BLOCK or PROMPT; detection patterns cover SSNs, account identifiers in CIP context	Audit entries with CIP-relevant DLP labels; PROMPT governance records
Recordkeeping (31 CFR § 1010.430)	Audit trail retains enforcement event records; configure SIEM retention to meet 5-year BSA minimum	Compliance export with full date-range coverage; SIEM retention configuration
Currency Transaction Reports (31 CFR § 1010.310)	CTR threshold indicators ($10,000+) trigger PROMPT governance for compliance team review	PROMPT action audit records; DLP trigger events
SR 11-7 Model Risk Management	Applicable where regulated financial institutions use AI models for AML screening or risk assessment; Model Registry governs approval and validation lifecycle	Model inventory export; approval log
FinCEN 314(b) information sharing	SSN and account detection events logged with full user context to support information sharing requests	Compliance export filtered by entity type; audit log search by user

Customer responsibilities

AML compliance program designation (BSA Compliance Officer)
SAR filing decisions and timing (Arbitex provides detection signal; filing is organizational)
Customer Due Diligence (CDD) / Know Your Customer (KYC) program
Currency Transaction Report (CTR) filing
OFAC/sanctions screening programs
Independent AML audit
FinCEN 314(a) information requests

CCPA

Standard: California Consumer Privacy Act as amended by CPRA (Cal. Civ. Code § 1798.100 et seq.) Regulatory body: California Privacy Protection Agency (CPPA) Scope: For-profit businesses operating in California meeting revenue or data-processing thresholds. AI systems processing California consumer personal information are in scope.

Requirements addressed by Arbitex

CCPA / CPRA Provision	Arbitex controls	Evidence artifacts
§ 1798.100 — Right to Know / Right to Delete	Arbitex does not retain prompt/completion content; audit entries log category, not PI content — limiting the PI footprint in Arbitex systems	Audit log schema confirmation; no content retention documentation
§ 1798.100(a)(3) — Data minimization (CPRA)	Policy Engine enforces purpose limitation; groups with different authorized purposes have separate policy rules scoping permissible data	Group policy definitions; enforcement audit entries by group
§ 1798.150 — Security obligation	Encryption in transit (TLS) and at rest (Azure platform AES-256 + Fernet application layer); audit trail for all PI processing	Security architecture documentation; audit log coverage
CPRA — Sensitive PI restrictions	BLOCK action prevents unauthorized use or disclosure of CCPA sensitive PI categories (government IDs, financial credentials, health data, precise geolocation, racial/ethnic origin)	DLP trigger events with sensitive PI labels; BLOCK audit entries
CCPA consumer rights workflow support	Audit exports filterable by user identity to support right-to-know and deletion scoping	Compliance export filtered by `user_id`; compliance export API
Data inventory support	Personal information detection logs used to scope data inventory responses to “know” requests	Audit log search by entity type; DLP label taxonomy

Customer responsibilities

Privacy policy and notice at collection
Opt-out of sale/sharing mechanisms (§ 1798.135) — requires customer-side signals
Consumer rights request intake and fulfillment workflows
Annual cybersecurity audit (CPRA requirement for high-risk processing)
Contractor/service provider contractual provisions
Data Protection Assessment for high-risk processing activities

SEC Reg FD

Standard: SEC Regulation Fair Disclosure (17 CFR Part 243) Regulatory body: U.S. Securities and Exchange Commission Scope: Issuers subject to Regulation FD. The rule governs selective disclosure of material non-public information (MNPI) — it is a disclosure rule, not a recordkeeping rule.

Requirements addressed by Arbitex

Reg FD consideration	Arbitex controls	Evidence artifacts
Detection of MNPI before it leaves the organization	`sec_reg_fd` bundle detects `insider_info`, `material_contract`, `regulatory_action`, `bank_account_number`, and `email` in AI traffic	DLP trigger events tagged with the bundle’s `compliance_bundle` tag; SIEM enforcement events
Preventing MNPI disclosure to third-party AI providers	Policy Engine BLOCK or REDACT action on bundle rule match, across every configured channel module	Policy enforcement records; override audit records for any exception
Evidence that a disclosure control was operating	Tamper-evident audit trail with HMAC chain; enforcement events exported via OCSF	Compliance export with full date-range coverage; chain verification report

Customer responsibilities

For Regulation FD:

Determining what information is “material” and “non-public” for your issuer
Public disclosure process following any inadvertent selective disclosure
Coverage of disclosure channels outside the AI Gateway (calls, meetings, email, messaging)

If you are a registered broker-dealer subject to SEC Rule 17a-4, that obligation rests entirely with you and is not addressed by this or any other Arbitex bundle:

A WORM archive meeting the non-rewritable, non-erasable requirement
Retention for the full required period (3 years for most books and records; 6 years for certain records)
Designation of a third-party download agent (required by Rule 17a-4(f)(3))
Examination access procedures for SEC examination staff
Record indexing of communications outside the AI Gateway (email, voice, messaging)

Evidence Collection for Auditors

Compliance export API

The Compliance Export API produces signed JSON packages suitable for presenting to auditors. The package includes HMAC chain verification, confirming the audit records have not been modified since they were written.

# Export all HIPAA enforcement events for a date range
curl -X POST https://api.arbitex.ai/api/v1/admin/audit/export \
  -H "Authorization: Bearer arb_live_your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "framework": "HIPAA",
    "from": "2026-01-01T00:00:00Z",
    "to": "2026-03-31T23:59:59Z",
    "format": "signed_json"
  }'

Repeat with framework set to the appropriate bundle ID (PCI-DSS, GDPR, GLBA, SOX, BSA_AML, CCPA, SEC_17A4) to produce per-framework evidence packages.

Portal export (filtered pull)

For ad-hoc audit queries, use the portal export endpoint:

# Export all DLP block events, CSV format
curl "https://api.arbitex.ai/v1/orgs/{org_id}/audit/export?format=csv&action=dlp_block&start_time=2026-01-01T00:00:00Z&end_time=2026-03-31T23:59:59Z" \
  -H "Authorization: Bearer <org_jwt>"

Supported filter parameters: format (csv/json), action, user_id, start_time, end_time, severity, limit (max 10,000 per request; use the compliance export API for larger pulls).

SIEM dashboard filters by framework

Use the following SIEM queries to scope enforcement event views to specific frameworks:

Framework	SIEM filter
PCI-DSS	`class_uid = 2001 AND metadata.framework_reference: "PCI-DSS*"`
HIPAA	`class_uid = 2001 AND metadata.framework_reference: "HIPAA*"`
GDPR	`class_uid = 2001 AND metadata.framework_reference: "GDPR*"`
GLBA	`class_uid = 2001 AND metadata.framework_reference: "GLBA*"`
SOX	`class_uid = 2001 AND metadata.framework_reference: "SOX*"`
BSA/AML	`class_uid = 2001 AND metadata.framework_reference: "BSA*"`
CCPA	`class_uid = 2001 AND metadata.framework_reference: "CCPA*"`
SEC Reg FD	`class_uid = 2001 AND metadata.framework_reference: "SEC Reg FD*"`
All enforcement events	`class_uid = 2001`
Authentication events	`class_uid = 3002`
Admin/policy changes	`class_uid = 3001`

Audit log HMAC chain verification

To confirm your audit trail has not been modified, use the chain verification API:

POST https://api.arbitex.ai/api/v1/admin/audit/verify
Authorization: Bearer arb_live_your-api-key
Content-Type: application/json

{
  "from": "2026-01-01T00:00:00Z",
  "to": "2026-03-31T23:59:59Z"
}

The response includes:

verified: true if the chain is intact for the requested range
entries_checked: count of audit entries verified
first_entry_id and last_entry_id: boundary records of the verified range
chain_status: details of any gaps or broken links detected

Present the verification response alongside the compliance export as evidence that audit records are tamper-evident. See Audit Chain Integrity for a complete description of the HMAC-SHA256 chain algorithm.

For organizations with OCC SR 11-7 obligations (financial institutions under GLBA, SOX, BSA/AML), export the model inventory to produce a model risk register artifact:

# JSON format for GRC platform import
GET https://api.arbitex.ai/api/v1/admin/model-inventory-export?format=json

# CSV format for spreadsheet or SR 11-7 examination submission
GET https://api.arbitex.ai/api/v1/admin/model-inventory-export?format=csv

The export includes model_id, provider, risk_tier, validation_status, owner, approved_use_cases, restrictions, usage_30d, usage_90d, and last_used_at. See Model Risk Management for the full field reference.

Bundle activation history

Bundle activation and deactivation events are logged as administrative changes (OCSF class 3001 — Account Change). To retrieve bundle activation history for an audit period:

curl "https://api.arbitex.ai/v1/orgs/{org_id}/audit/export?format=json&action=bundle_state_change&start_time=2026-01-01T00:00:00Z" \
  -H "Authorization: Bearer <org_jwt>"

Each event includes the bundle_id, the enabled state before and after the change, the admin user ID, and the timestamp. This record supports demonstrating continuous compliance coverage to auditors.

Multi-Framework Deployments

Organizations with overlapping regulatory obligations — such as a healthcare payment processor subject to both HIPAA and PCI-DSS, or a bank subject to GLBA, SOX, and BSA/AML — can activate multiple bundles simultaneously.

Activating multiple bundles

Enable each bundle individually, then add all bundles to your policy chain:

# Enable all required bundles
POST https://api.arbitex.ai/api/v1/admin/orgs/{org_id}/compliance/bundles
{ "bundle_id": "hipaa", "enabled": true }

POST https://api.arbitex.ai/api/v1/admin/orgs/{org_id}/compliance/bundles
{ "bundle_id": "pci_dss", "enabled": true }

POST https://api.arbitex.ai/api/v1/admin/orgs/{org_id}/compliance/bundles
{ "bundle_id": "glba", "enabled": true }

# Configure the policy chain with sequence ordering
PUT https://api.arbitex.ai/api/v1/admin/orgs/{org_id}/policy/chain
{
  "combining_algorithm": "first_applicable",
  "packs": [
    { "pack_id": "bundle_hipaa",   "sequence": 1 },
    { "pack_id": "bundle_pci_dss", "sequence": 2 },
    { "pack_id": "bundle_glba",    "sequence": 3 },
    { "pack_id": "pack_01HZ_CUSTOM", "sequence": 10 }
  ]
}

Chain ordering guidance

Under the default first_applicable combining algorithm, the first matching rule across the chain terminates evaluation for that request. This has practical implications for multi-bundle deployments:

Position the most restrictive bundle first. If HIPAA and GLBA both target SSNs, HIPAA’s BLOCK rule fires first when HIPAA is at a lower sequence number. The GLBA rule does not produce a separate event for the same request under first_applicable.
Use deny_overrides if you need all bundles to produce audit evidence independently. Under deny_overrides, all packs evaluate — any BLOCK from any bundle takes precedence, and all matching rules log audit entries. This produces richer audit evidence at the cost of increased policy evaluation overhead.
Custom ALLOW rules before bundles. If a specific group has a business justification to transmit data that a bundle would block, position a custom ALLOW rule in a pack before the bundles in the chain. This bypass is explicit and produces an ALLOW_WITH_OVERRIDE audit entry.

Shared detectors across bundles

Several DLP entity types are activated by multiple bundles simultaneously:

Entity type	Active in bundles
`ssn`	HIPAA, GLBA, CCPA, BSA/AML
`financial_account_numbers`	GLBA, SOX, BSA/AML, SEC 17a-4
`email`	GDPR, CCPA, SEC 17a-4
`health_info`	HIPAA, GDPR
`biometric`	GDPR, CCPA
`name`	HIPAA, GDPR, CCPA
`bank_account_number`	PCI-DSS, BSA/AML

When multiple bundles are active and a shared detector fires, the audit entry references the framework of the bundle whose rule matched first (under first_applicable) or all matching bundles (under deny_overrides). Shared detectors do not double-evaluate — the DLP pipeline runs once per request.

Common multi-framework combinations

Organization type	Typical bundle set	Recommended chain order
Healthcare payment processor	HIPAA, PCI-DSS	HIPAA (1), PCI-DSS (2)
Regional bank	GLBA, BSA/AML, SOX	GLBA (1), BSA/AML (2), SOX (3)
Broker-dealer	SEC Reg FD, BSA/AML, SOX	SEC Reg FD (1), BSA/AML (2), SOX (3)
Financial services (full stack)	GLBA, PCI-DSS, BSA/AML, SOX, SEC Reg FD	PCI-DSS (1), GLBA (2), BSA/AML (3), SOX (4), SEC Reg FD (5)
EU healthcare organization	GDPR, HIPAA	GDPR (1), HIPAA (2)
Multi-state consumer lender	GLBA, CCPA	GLBA (1), CCPA (2)

Shared Responsibility Model

Arbitex provides controls at the AI Gateway layer. Your organization is responsible for the broader compliance program surrounding the AI Gateway.

Compliance area	Arbitex provides	Customer provides
Data detection	DLP inline scanning with framework-specific entity patterns on every request	Accurate scoping of which systems/users route through the Gateway
Enforcement	Policy Engine with BLOCK, CANCEL, REDACT, ALLOW_WITH_OVERRIDE, PROMPT actions	Business logic for when to allow, block, or route to human review
Audit trail	Tamper-evident HMAC-chained log of all platform events, immutable and append-only	Retention beyond 2 years (configure SIEM); log integration into your GRC platform
SIEM integration	OCSF v1.1 export; standard field schema; framework_reference metadata	SIEM platform provisioning, retention configuration, alerting rules
Access controls	RBAC roles, group-based policy rules, SAML SSO, MFA enforcement	User provisioning and deprovisioning; HR processes; access recertification
Encryption	TLS 1.2+ in transit; Fernet application-layer encryption; mTLS on internal connections	Key management (BYOK planned); customer-side encryption at rest
Model risk (SR 11-7)	Model Registry, risk tiers, validation lifecycle, immutable approval log, policy enforcement	Model validation execution; SR 11-7 documentation; examination submission
Compliance program governance	None — Arbitex is a control in your program, not the program itself	Designated compliance officer, board reporting, regulatory filings, examinations
Regulatory filings	None	SAR filing (BSA/AML), CTR filing, breach notifications, privacy notices
Third-party management	Data Processing Agreements available	Vendor risk management program; DPA execution; BAA signing
Certification	None — Arbitex is not certified under any framework	Certification and audit engagement where required (e.g., PCI-DSS QSA assessment)

Compliance Mapping Guide

Control Matrix

Capability descriptions

Framework-by-Framework Mapping

PCI-DSS

Requirements addressed by Arbitex

Customer responsibilities (not covered by Arbitex)

HIPAA

Requirements addressed by Arbitex

Customer responsibilities

GDPR

Requirements addressed by Arbitex

Customer responsibilities

GLBA

Requirements addressed by Arbitex

Customer responsibilities

SOX

Requirements addressed by Arbitex

Customer responsibilities

BSA/AML

Requirements addressed by Arbitex

Customer responsibilities

CCPA

Requirements addressed by Arbitex

Customer responsibilities

SEC Reg FD

Requirements addressed by Arbitex

Customer responsibilities

Evidence Collection for Auditors

Compliance export API

Portal export (filtered pull)

SIEM dashboard filters by framework

Audit log HMAC chain verification

Model inventory export for SR 11-7

Bundle activation history

Multi-Framework Deployments

Activating multiple bundles

Chain ordering guidance

Shared detectors across bundles

Common multi-framework combinations

Shared Responsibility Model

See Also