Compliance Engine

Compliance that changes system behavior, not just customer confidence.

The Compliance Engine sits inside WorkSwarm runtime. It governs residency, consent, retention, classification, lawful basis, and sub-processor access so enterprise policy is enforced during execution, not checked later in a spreadsheet.

Return to Trust Center See activation model

Policy as codeCompliance-pack activationResidency enforcementRetention and consent controlsSub-processor policy mediationAudit-ready evidence generation

Enterprise setup proof

How compliance moves from selection to enforcement

Runtime posture

Choose residency

Enterprise setup starts with where tenant data is allowed to live and where it is not allowed to go.

Activate packs

HIPAA, PCI, DPDP, GDPR, and similar packs become explicit runtime posture rather than aspirational documentation.

Enforce policy

Writes, transfers, retention, consent checks, and sub-processor usage all flow through the same enforcement layer.

Generate evidence

The same runtime state produces proof for audit, procurement, and internal governance.

Why runtime enforcement matters

A policy document does not stop a bad write, a bad transfer, or a missing consent check.

The buying story here is straightforward: enterprise admins select a trust and compliance posture during setup, and the engine turns that posture into execution rules that can allow, block, log, escalate, or require extra approval.

HIPAA posture

Restricts eligible providers, tightens data handling, and raises the bar for PHI-related operations.

PCI posture

Tokenization and payment-data controls move into runtime decisions rather than documentation promises.

DPDP and GDPR posture

Residency, consent, lawful basis, and deletion workflows become active controls on system behavior.

Customer overlays

Tenants can tighten beyond defaults, but not relax beneath the regulatory floor enforced by the engine.

What the Compliance Engine does

11 subsystems that gate every operation at the platform layer - not in documentation.

Policy Catalog

Versioned, machine-readable rules per regulation, sector, and customer overlay. Updates per regulation change; signed; audited.

Classification Engine

Tags every record with classification at write time. Reclassifies on user input or scan. Surfaces unclassified to admins.

Residency Enforcer

Refuses cross-region writes that violate residency. Approves with consent; requires TIA documentation.

Retention Scheduler

Triggers deletion at TTL; honors legal hold; surfaces conflicts to compliance dashboard.

Consent Resolver

Verifies consent at processing time; refuses without; honors withdrawal cascade.

Lawful Basis Resolver

Confirms one of the six GDPR-style bases or local equivalent; documents the basis per record.

DSR Orchestrator

Receives, verifies, executes data subject requests within SLA per regulation.

Sub-processor Mediator

Allows or denies sub-processor access per customer policy; logs every decision.

Cross-Border Auditor

Logs every cross-border transfer; produces TIAs; alerts on volume changes.

PII Redactor

Inline at every boundary; per-tenant rules; tested per release with failure tests blocking deploy.

Compliance Dashboard

Customer-facing live state; control evidence; one-click audit package generation.

Policy as code

Regulations become declarative rules. Engineers extend the engine by adding rules, not by writing one-off code. Compliance team owns rule authorship; engineering owns the runtime.

RBI payment data localization

rule rbi-payment-data-localization {
  applies_when: data.classification == "payment_system_data"
                && tenant.regulator_aware == "RBI"
  enforce: data.region in ["ap-south-1", "ap-south-2"]
  enforce: data.replicated_regions intersect ["non-india"] is empty
  on_violation: refuse_write, log, alert_admin, alert_compliance
}

GDPR cross-border transfer

rule gdpr-cross-border-transfer {
  applies_when: data.subject_jurisdiction == "EU"
                && transfer.destination not in adequacy_list
  enforce: tia.exists && scc.signed && supplementary_measures.adequate
  on_violation: refuse_transfer, log, customer_notify
}

DPDP Act erasure request

rule dpdp-erasure-request {
  applies_when: dsr.kind == "erasure" && dsr.jurisdiction == "IN"
  sla: 30_days
  cascade: all_storage, all_caches, all_search_indexes, audit_pseudonymize
  exceptions: legal_hold, statutory_retention
  evidence: certificate_of_completion
}

Go next

Runtime compliance is the bridge between trust claims and enterprise rollout.

This page makes the most sense when read alongside the trust surface, the security posture, and the enterprise onboarding path that turns compliance selection into tenant behavior.

Trust Center

See the broader trust posture, evidence library, deployment models, and regulator-facing story.

Open route →

Trust in Product

See how admins inspect runtime trust state, pack effects, and operational evidence inside the app.

Open route →

For Enterprise

See how domain claim, SSO, residency, and pack activation fit into the buyer journey.

Open route →

Security

See the adjacent control model for AI runtime boundaries, tool execution, and tenant-scoped action.

Open route →

Customer overlays

You can tighten beyond WorkSwarm's defaults - you cannot loosen below the regulator's floor. This is the right model for enterprise policy posture: configurable where risk appetite differs, fixed where the control baseline cannot be compromised.

✅ You can

• Shorten retention below defaults
• Add additional consent requirements
• Restrict sub-processor access per workspace
• Require stricter MFA (hardware keys only)
• Add custom data classification labels

🚫 You cannot

• Disable encryption at rest
• Remove audit logging
• Bypass data residency enforcement
• Override legal hold for deletion
• Skip DSR automation SLAs

Live evidence generation

One-click audit packages, auto-populated from runtime state - not manually maintained spreadsheets.

SOC 2 controls evidence (auto-populated from runtime)
ISO 27001 ISMS evidence (auto-populated)
HITRUST CSF evidence (auto-populated)
RBI-examiner evidence package
IRDAI annual audit evidence
GDPR ROPA (auto-generated from data inventory)
HIPAA risk assessment helper
Custom compliance posture score

Compliance matrix

Which regulations each architecture satisfies

Pick the row that matches your environment. Every checked cell is an enforceable invariant in the architecture, not a marketing claim.

Architecture	DPDP Act 2023	ISO 27001	SOC 2	HIPAA Privacy	HIPAA Security	RBI Localization	PCI DSS	CERT In	Attorney Client Privilege	GDPR Processor	Bar Council Rules	GST Rules	IT Act 2000	India Residency
Tally Prime Local desktop only	✓	✓
Healthcare Patient data and PHI	✓	✓	✓	✓	✓
BFSI Banks and lenders	✓		✓			✓	✓	✓
Legal Contracts and deals		✓							✓	✓	✓
GST and Tax India residency	✓											✓	✓	✓

Checked cells indicate the architecture is designed to satisfy the regulation by data flow, not by paperwork alone. For audited certifications and standing reports, see the Trust Center.

← Back to Trust Center