Compliance Reporting

Compliance Reporting

Arbitex Cloud provides built-in compliance reporting that maps your DLP controls, detection policies, and audit trails directly to the requirements of major regulatory frameworks. Instead of manually gathering evidence and cross-referencing policy configurations against framework controls, you generate a structured report that captures the current compliance posture of your organization at a point in time.

Compliance reports are available on the Enterprise plan.

---

Compliance Overview

Supported Frameworks

Arbitex Cloud supports compliance reporting for five frameworks:

Framework	Full Name	Primary Concern
hipaa	Health Insurance Portability and Accountability Act	Protected Health Information (PHI) in transit and at rest
pci_dss	Payment Card Industry Data Security Standard	Cardholder data protection and transmission security
sox	Sarbanes-Oxley Act	Financial data integrity and access controls
gdpr	General Data Protection Regulation	Personal data of EU residents — collection, processing, and transfer
soc2	Service Organization Control 2 (Trust Services Criteria)	Security, availability, processing integrity, confidentiality, privacy

What Compliance Reporting Covers

In the context of DLP, compliance reporting answers a specific subset of each framework’s requirements: those that relate to data detection, handling, and access controls. Arbitex does not generate reports covering infrastructure security, physical controls, or HR procedures — those remain your responsibility.

For each supported framework, Arbitex maps the following platform capabilities to framework controls:

• Detection policies — which data types are monitored, which outposts enforce them, and whether enforcement is in block or audit mode
• Pattern libraries — whether the correct detection patterns (SSNs, credit card numbers, PHI terms, etc.) are active for the data types the framework protects
• Audit trails — completeness and retention of the audit log, including policy enforcement events, admin actions, and authentication events
• Access controls — which users have admin or compliance officer roles, how authentication is configured (MFA, SSO), and whether role-based access meets separation of duties requirements
• Data residency — which regions your data is processed and stored in (relevant to GDPR and HIPAA)
• Encryption — confirmation that data-in-transit (TLS) and data-at-rest protections are enabled

Control Statuses

Every control in a compliance report carries one of three statuses:

Status	Meaning
compliant	The control is fully satisfied. Evidence is present and passes all checks.
partial	The control is partially satisfied. Some evidence is present but gaps exist — for example, a detection policy is active but not enforced across all outposts.
gap	The control is not satisfied. Required configuration is absent or evidence is missing. Action is required before this control can be considered compliant.

A report summary aggregates the counts across all controls in the framework. A report with zero gap controls and zero partial controls represents full framework coverage for the DLP-relevant subset of that framework’s requirements.

Framework-to-Feature Mapping

The following table illustrates how Arbitex features map to selected controls across frameworks. This is not exhaustive — the full control list appears in generated reports.

Framework	Example Control	Arbitex Feature
HIPAA	§ 164.312(e)(2)(ii) — Encryption in transit	TLS enforcement on all outpost connections
HIPAA	§ 164.312(b) — Audit controls	Audit log with PHI access events and retention policy
PCI DSS	Req 3.4 — PAN masking	Credit card detection policy with masking/block action
PCI DSS	Req 10.2 — Audit trail	Audit log events for all cardholder data access
SOX	Section 404 — Internal controls	Role-based access, separation of duties via admin roles
GDPR	Art. 32 — Technical measures	DLP enforcement on personal data; data residency configuration
GDPR	Art. 30 — Records of processing	Audit log of personal data detection and handling events
SOC 2	CC6.1 — Logical access	MFA enforcement, SSO configuration, session policies
SOC 2	CC7.2 — Detection of anomalies	DLP alert rules and incident response configuration

---

Generating Reports

Reports are generated asynchronously. You submit a generation request with the desired framework and date range, receive a report_id, and then poll for completion.

Endpoint

POST /v1/orgs/{org_id}/compliance/report

Required scope: compliance:write

Request Body — ComplianceReportRequest

Field	Type	Required	Description
framework	string (enum)	Yes	One of: hipaa, pci_dss, sox, gdpr, soc2
date_range.start	string (ISO 8601)	Yes	Start of the reporting period, inclusive (e.g., 2026-01-01T00:00:00Z)
date_range.end	string (ISO 8601)	Yes	End of the reporting period, inclusive (e.g., 2026-03-31T23:59:59Z)

Example Request

curl -s -X POST \
  -H "X-API-Key: arx_your_compliance_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "framework": "hipaa",
    "date_range": {
      "start": "2026-01-01T00:00:00Z",
      "end": "2026-03-31T23:59:59Z"
    }
  }' \
  "https://api.arbitex.ai/v1/orgs/{org_id}/compliance/report"

Initial Response — Generating

The API immediately returns a report object with status: "generating":

{
  "id": "rpt_01j9x2z5p3q6r7s8t9u0v1w2",
  "framework": "hipaa",
  "period_start": "2026-01-01T00:00:00Z",
  "period_end": "2026-03-31T23:59:59Z",
  "status": "generating",
  "summary": null,
  "generated_at": null,
  "generated_by": "key:key_01j8x9z3p2q4r5s6t7u8v9w0"
}

Report generation typically completes within 30–120 seconds depending on the size of your audit log and the number of controls in the framework.

Polling for Completion

Poll the report status endpoint until status changes from "generating" to "completed" or "failed":

GET /v1/orgs/{org_id}/compliance/reports/{report_id}

Required scope: compliance:read

curl -s \
  -H "X-API-Key: arx_your_compliance_key_here" \
  "https://api.arbitex.ai/v1/orgs/{org_id}/compliance/reports/rpt_01j9x2z5p3q6r7s8t9u0v1w2"

Completed Response — ComplianceReportResponse

When generation completes, the response includes the summary object with control counts:

{
  "id": "rpt_01j9x2z5p3q6r7s8t9u0v1w2",
  "framework": "hipaa",
  "period_start": "2026-01-01T00:00:00Z",
  "period_end": "2026-03-31T23:59:59Z",
  "status": "completed",
  "summary": {
    "total_controls": 18,
    "compliant": 14,
    "partial": 3,
    "gap": 1
  },
  "generated_at": "2026-03-15T09:14:22Z",
  "generated_by": "key:key_01j8x9z3p2q4r5s6t7u8v9w0"
}

ComplianceReportResponse Schema

Field	Type	Description
id	string	Unique report identifier
framework	string	The framework the report covers
period_start	string (ISO 8601)	Start of the reporting period
period_end	string (ISO 8601)	End of the reporting period
status	string	generating, completed, or failed
summary.total_controls	integer	Total number of controls evaluated
summary.compliant	integer	Number of controls with compliant status
summary.partial	integer	Number of controls with partial status
summary.gap	integer	Number of controls with gap status
generated_at	string (ISO 8601)	Timestamp when generation completed (null while generating)
generated_by	string	Identity that triggered the report — user ID or API key reference

Listing Reports

To retrieve all reports generated for your organization:

GET /v1/orgs/{org_id}/compliance/reports

Returns an array of ComplianceReportResponse objects, ordered by generated_at descending. Use query parameters framework and status to filter results:

curl -s \
  -H "X-API-Key: arx_your_compliance_key_here" \
  "https://api.arbitex.ai/v1/orgs/{org_id}/compliance/reports?framework=hipaa&status=completed"

---

Framework Coverage Matrix

The coverage matrix provides a real-time view of your compliance posture — distinct from a point-in-time report. While a generated report reflects a specific date range (including historical evidence), the coverage matrix reflects the current configuration of your organization.

Endpoint

GET /v1/orgs/{org_id}/compliance/coverage

Required scope: compliance:read

Query parameter framework is required:

curl -s \
  -H "X-API-Key: arx_your_compliance_key_here" \
  "https://api.arbitex.ai/v1/orgs/{org_id}/compliance/coverage?framework=pci_dss"

CoverageMatrix Schema

Field	Type	Description
framework	string	The framework identifier
evaluated_at	string (ISO 8601)	Timestamp of the coverage evaluation
controls	array	Array of ControlCoverage objects

ControlCoverage Schema

Field	Type	Description
control_id	string	Framework-specific control identifier (e.g., HIPAA-164.312b, PCI-Req10.2)
control_name	string	Human-readable control name
status	string	compliant, partial, or gap
evidence	array of strings	List of evidence items that contribute to this control’s status

Sample Coverage Matrix Response

{
  "framework": "pci_dss",
  "evaluated_at": "2026-03-15T10:30:00Z",
  "controls": [
    {
      "control_id": "PCI-Req3.4",
      "control_name": "Render PAN unreadable anywhere it is stored",
      "status": "compliant",
      "evidence": [
        "Detection policy 'Credit Card Numbers' is active and set to BLOCK mode",
        "Policy enforced on 4 of 4 registered outposts",
        "0 unmasked PANs detected in the last 90 days"
      ]
    },
    {
      "control_id": "PCI-Req10.2",
      "control_name": "Implement audit trails to reconstruct events",
      "status": "partial",
      "evidence": [
        "Audit log is enabled and retaining events for 90 days",
        "Authentication events (10.2.4) are captured",
        "Admin action events (10.2.5) are captured",
        "WARNING: Audit log retention is below the PCI DSS recommended 12-month minimum — current retention is 90 days"
      ]
    },
    {
      "control_id": "PCI-Req8.3",
      "control_name": "Secure individual non-consumer user authentication",
      "status": "gap",
      "evidence": [
        "MFA is not enforced for admin users — 3 of 7 admins have MFA disabled",
        "SSO is not configured — local password authentication is in use without MFA requirement"
      ]
    }
  ]
}

Interpreting Coverage Status

compliant — All evidence items pass. No action required. The control will remain compliant as long as the underlying configuration is not changed.

partial — Some evidence is present but not all criteria are met. The control will appear in a generated report as partial. Review the evidence array — each item describes what passed and what is deficient. Address the deficiencies and re-evaluate to move the control to compliant.

gap — No qualifying evidence found, or a required configuration is absent. The evidence array describes what is missing. A gap control represents a material deficiency that must be remediated before you can assert compliance with this framework requirement.

Caution

The coverage matrix reflects your current configuration. It does not retroactively affect reports that have already been generated. If you remediate a gap control today and then generate a new report covering a past period, the report will still reflect the state during that period — not the current configuration.

---

Exporting Reports

Once a report has status: "completed", you can download it in three formats.

Endpoint

GET /v1/orgs/{org_id}/compliance/reports/{report_id}/export?format={pdf|csv|json}

Required scope: compliance:read

The format query parameter is required. The response includes a Content-Disposition: attachment header with an appropriate filename.

Format Options

Format	Use Case	Content
pdf	Executive review, auditor submission	Executive summary, framework overview, control-by-control detail with evidence, remediation guidance for gap and partial controls
csv	Spreadsheet analysis, GRC platform import	Tabular — one row per control with columns for control ID, name, status, and evidence (semicolon-delimited within the evidence cell)
json	SIEM integration, GRC tool ingestion, programmatic processing	Machine-readable — full ComplianceReportResponse plus complete controls array with all evidence items

PDF Export

curl -s \
  -H "X-API-Key: arx_your_compliance_key_here" \
  -o "hipaa-q1-2026.pdf" \
  "https://api.arbitex.ai/v1/orgs/{org_id}/compliance/reports/rpt_01j9x2z5p3q6r7s8t9u0v1w2/export?format=pdf"

The PDF is structured as follows:

1. Cover page — Organization name, framework, reporting period, report ID, generated timestamp
2. Executive summary — Control counts (compliant / partial / gap), overall compliance posture narrative, top gaps requiring immediate action
3. Framework overview — Brief description of the framework and the scope of Arbitex’s coverage
4. Control detail — One section per control: control ID, control name, status badge, evidence list, and (for gap and partial controls) remediation guidance
5. Appendix — Glossary of control statuses, scope limitations, and contact information for Arbitex compliance support

CSV Export

curl -s \
  -H "X-API-Key: arx_your_compliance_key_here" \
  -o "hipaa-q1-2026.csv" \
  "https://api.arbitex.ai/v1/orgs/{org_id}/compliance/reports/rpt_01j9x2z5p3q6r7s8t9u0v1w2/export?format=csv"

Column layout:

Column	Description
control_id	Framework control identifier
control_name	Human-readable control name
status	compliant, partial, or gap
evidence	Evidence items, semicolon-delimited within a single cell
remediation_guidance	Populated for gap and partial controls; empty for compliant

JSON Export

curl -s \
  -H "X-API-Key: arx_your_compliance_key_here" \
  -o "hipaa-q1-2026.json" \
  "https://api.arbitex.ai/v1/orgs/{org_id}/compliance/reports/rpt_01j9x2z5p3q6r7s8t9u0v1w2/export?format=json"

The JSON export includes the full report object plus the complete controls array — identical in structure to the coverage matrix controls array but scoped to the reporting period rather than the current configuration. This format is suitable for:

• Ingesting into a SIEM (Splunk, Microsoft Sentinel, Elastic Security) for long-term retention and correlation
• Importing into a GRC platform (ServiceNow GRC, OneTrust, Drata, Vanta)
• Custom dashboards or compliance tracking tools built by your team

---

Review Workflow

Evidence Review

After generating a report, a compliance officer should review the evidence for each control before using the report for an audit submission or internal governance review.

The recommended review process:

1. Export as PDF — use the PDF for the primary review. Each control section lists its evidence items explicitly.
2. Verify compliant controls — confirm that the evidence accurately reflects your configuration. In rare cases, evidence may be present but stale (e.g., a policy was active during the reporting period but has since been deleted).
3. Triage partial controls — determine whether each partial control represents a genuine gap or a gap in Arbitex’s evidence collection. If the control is actually satisfied by controls outside Arbitex’s scope (e.g., network-layer encryption), annotate accordingly in your GRC tool.
4. Escalate gap controls — each gap control requires a remediation owner and a target completion date. Create action items in your GRC platform or ticketing system.

Gap Remediation

For each gap or partial control:

1. Identify the remediation action — the PDF report includes remediation guidance for each non-compliant control. The guidance is specific to the control and your current configuration.
2. Assign an owner — a team member or team responsible for implementing the fix.
3. Implement the change in Arbitex (e.g., enable a detection policy, enforce MFA, extend audit log retention).
4. Re-evaluate coverage — after implementing the change, query the coverage matrix to confirm the control’s status has moved to compliant:

curl -s \
  -H "X-API-Key: arx_your_compliance_key_here" \
  "https://api.arbitex.ai/v1/orgs/{org_id}/compliance/coverage?framework=hipaa"

5. Generate a new report covering the remediation period if you need to document the remediated state for auditors.

Scheduled Reports

You can configure Arbitex to automatically generate compliance reports on a schedule and deliver them to designated recipients via email. Scheduled reports are useful for:

• Monthly compliance posture reviews
• Quarterly auditor deliverables
• Continuous monitoring programs that require a periodic compliance snapshot

Endpoint:

POST /v1/orgs/{org_id}/compliance/schedules

Required scope: compliance:write

Request body:

Field	Type	Required	Description
framework	string (enum)	Yes	Framework to report on
cron	string	Yes	Cron expression defining the schedule (UTC)
recipients	array of strings	Yes	Email addresses to receive the generated report
export_format	string	No	Format to attach to the email: pdf (default), csv, or json
enabled	boolean	No	Whether the schedule is active. Defaults to true.

Example — Monthly HIPAA report delivered to the compliance team:

curl -s -X POST \
  -H "X-API-Key: arx_your_compliance_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "framework": "hipaa",
    "cron": "0 6 1 * *",
    "recipients": [
      "[email protected]",
      "[email protected]"
    ],
    "export_format": "pdf",
    "enabled": true
  }' \
  "https://api.arbitex.ai/v1/orgs/{org_id}/compliance/schedules"

This schedule generates a HIPAA compliance report on the first day of every month at 06:00 UTC, covering the previous calendar month, and emails the PDF to the specified recipients.

Tip

Schedule quarterly reports to align with your internal governance calendar. For SOC 2, generate reports at the end of each quarter to build an audit trail for your annual SOC 2 audit period. The reporting period is automatically set to cover the interval since the previous scheduled run.

Listing and managing schedules:

# List all schedules
curl -s \
  -H "X-API-Key: arx_your_compliance_key_here" \
  "https://api.arbitex.ai/v1/orgs/{org_id}/compliance/schedules"

# Disable a schedule without deleting it
curl -s -X PATCH \
  -H "X-API-Key: arx_your_compliance_key_here" \
  -H "Content-Type: application/json" \
  -d '{"enabled": false}' \
  "https://api.arbitex.ai/v1/orgs/{org_id}/compliance/schedules/{schedule_id}"

# Delete a schedule
curl -s -X DELETE \
  -H "X-API-Key: arx_your_compliance_key_here" \
  "https://api.arbitex.ai/v1/orgs/{org_id}/compliance/schedules/{schedule_id}"

---

Compliance FAQ

HIPAA — Does Arbitex sign a Business Associate Agreement (BAA)?

Caution

A signed BAA is required before you may use Arbitex to process, store, or transmit Protected Health Information (PHI). Do not use Arbitex Cloud for HIPAA-covered workloads without a fully executed BAA in place.

Yes. Arbitex signs BAAs with customers on the Enterprise plan. The BAA covers Arbitex’s role as a business associate in the detection, logging, and enforcement of DLP policies that touch PHI.

To initiate the BAA process, contact your Arbitex account executive or email [email protected] with your organization name and the name of the HIPAA covered entity. The BAA is countersigned by Arbitex’s legal team and returned within five business days.

BAAs are not available on Team or Starter plans. If you are evaluating Arbitex for a HIPAA use case, contact sales to discuss Enterprise plan options before processing any PHI.

HIPAA — How does Arbitex log workforce training completion for HIPAA requirements?

HIPAA’s Security Rule (§ 164.308(a)(5)) requires covered entities to implement a security awareness and training program for all workforce members. Arbitex logs training-relevant events when you use the Arbitex admin portal to assign and track policy acknowledgements:

• When an admin publishes a policy update, Arbitex records a policy.published audit event
• When a user acknowledges a policy in the portal, Arbitex records a policy.acknowledged audit event, including the user identity, timestamp, and policy version

These events are available in the audit log and can be exported to your training records system via the audit log export API. They constitute evidence for HIPAA § 164.308(a)(5) workforce training controls in a generated compliance report.

Arbitex does not deliver security awareness training content. For full HIPAA workforce training coverage, pair Arbitex’s acknowledgement logging with a dedicated security training platform (e.g., KnowBe4, Proofpoint Security Awareness Training).

PCI DSS — What documentation does Arbitex provide for audits?

Certification status

Arbitex does not hold a PCI DSS Attestation of Compliance (AOC), and is not certified or attested under PCI DSS or any other framework. Arbitex is designed for deployment within a cardholder data environment, but it is not itself an assessed entity. Do not represent Arbitex as PCI DSS certified or attested in your assessment.

Arbitex provides evidence that supports your PCI DSS assessment. It does not provide an attestation of its own:

• Self-Assessment Questionnaire (SAQ) guidance — Arbitex can provide a shared responsibility matrix mapping PCI DSS requirements to what Arbitex handles and what remains your responsibility as the merchant or service provider. Request via [email protected].
• Generated compliance reports — PCI DSS compliance reports generated via the Arbitex API serve as evidence for the cardholder data detection and audit log controls within your own assessment.
• Security architecture documentation — the control descriptions in the Security Trust Center describe the engineering implementation behind each control your assessor will review.

If Arbitex is deployed within your CDE scope, its infrastructure must be included in your own PCI DSS assessment. Arbitex cannot reduce that scope on the strength of an attestation it does not hold.

The Arbitex shared responsibility model for PCI DSS:

PCI DSS Requirement Area	Arbitex Responsibility	Your Responsibility
Req 3 — Protect stored cardholder data	PAN detection and masking/blocking at the proxy layer	Ensuring your storage systems do not retain PANs that bypass Arbitex
Req 7 — Restrict access	RBAC for Arbitex admin roles	Your broader cardholder data environment access controls
Req 10 — Track and monitor access	Audit log of all Arbitex events	Aggregating Arbitex logs with your CDE logs in your SIEM
Req 12 — Maintain an information security policy	DLP policy management and versioning	Your organization’s information security policies

SOX — How does Arbitex support segregation of duties requirements?

SOX Section 404 requires internal controls over financial reporting, including segregation of duties (SoD) — ensuring that no single individual has unchecked control over financial systems or data.

Arbitex supports SoD through its role-based access control (RBAC) system:

• Compliance Officer role — can view reports and audit logs but cannot modify DLP policies or user access
• Policy Admin role — can create and modify DLP policies but cannot view compliance reports or manage user accounts
• Org Admin role — full access; use of this role should be restricted to a small number of designated administrators and audited regularly

For SOX, the recommended configuration is:

1. Assign the Policy Admin role to the team responsible for DLP policy management
2. Assign the Compliance Officer role to auditors or finance team members who need to review compliance reports
3. Restrict the Org Admin role to IT security personnel with formal change management controls
4. Enable the audit log alert for role.assigned events so that any privilege changes are immediately visible to the security team

Arbitex’s generated SOX compliance report evaluates these role assignments and flags configurations where a single user holds both policy administration and compliance review privileges, which would represent an SoD violation.

GDPR — Does Arbitex offer EU data residency?

Yes. Arbitex Cloud supports EU data residency for organizations with GDPR obligations. When EU data residency is selected at org configuration:

• All customer data (audit logs, detection events, report data) is stored in Arbitex’s EU region (Amsterdam data center)
• Processing of your data does not leave the EU region
• No data transfers to Arbitex’s US or APAC regions occur for your organization

EU data residency must be selected at organization creation time. Migrating an existing organization from a non-EU region to EU data residency requires coordination with Arbitex support and involves a data migration window. Contact [email protected] to initiate a residency migration.

Data Processing Agreement (DPA): Organizations subject to GDPR must execute a DPA with Arbitex before processing personal data of EU residents. Arbitex’s standard DPA is available for download from the portal under Settings → Compliance Documents. The DPA covers Arbitex’s role as a data processor, data subject rights handling, sub-processor disclosures, and breach notification obligations.

Caution

If your organization is subject to GDPR and processes personal data of EU residents through Arbitex, a signed DPA is legally required. Generating a GDPR compliance report does not substitute for a DPA. Ensure the DPA is executed before using Arbitex in a GDPR-covered capacity.

GDPR Article 30 — Records of Processing Activities (RoPA): The Arbitex audit log, combined with your DLP policy configuration, constitutes the technical record of how personal data is detected, processed, and handled within Arbitex’s scope. The GDPR compliance report maps your audit log and policy configuration to the RoPA requirements. Export the JSON report and ingest it into your RoPA management tool to maintain an up-to-date record.

SOC 2 — Which Trust Services Criteria does Arbitex cover?

Arbitex’s compliance reporting covers the Security (CC) Trust Services Criteria relevant to DLP and access controls. Specifically:

Criteria	Description	Arbitex Coverage
CC6.1	Logical and physical access controls	Admin RBAC, MFA enforcement, SSO configuration
CC6.2	Prior to issuing credentials	API key creation workflow, single-reveal key design
CC6.3	Role-based access	Policy Admin, Compliance Officer, Org Admin role structure
CC7.2	Detection of anomalies	DLP alert rules, detection event monitoring
CC7.3	Incident response	DLP enforcement actions, block events as incident indicators
CC9.2	Vendor risk management	Arbitex’s AI governance controls across all five Trust Services Criteria

Arbitex is designed for SOC 2 Type II. Controls are implemented and operating across all five Trust Services Criteria. Formal attestation is in progress. Contact your account executive or [email protected] for details.

The SOC 2 compliance report generated by Arbitex covers only the DLP-relevant criteria listed above. For a full SOC 2 assessment of your own organization, you will need to map your broader infrastructure, change management, vendor management, and availability controls separately. Arbitex’s report serves as evidence for the access control and monitoring criteria within your own audit.

---

Required API Scopes Summary

Operation	Scope Required
Generate a compliance report	compliance:write
Retrieve a report or list reports	compliance:read
Get coverage matrix	compliance:read
Export a report (PDF, CSV, JSON)	compliance:read
Create a compliance schedule	compliance:write
List or manage schedules	compliance:read / compliance:write

Create a dedicated API key with the compliance:read and compliance:write scopes for all compliance automation. Do not use the admin scope for compliance integrations — the principle of least privilege applies.