Meeting GDPR, HIPAA & SOC 2 with On-Prem Analytics

For organizations in regulated industries, analytics is one of the riskiest places data can travel. A business intelligence platform touches your most sensitive datasets, generates queries against them, and distributes the results to dashboards and scheduled reports. When that platform is delivered as a multi-tenant cloud service, your compliance team inherits the provider's data handling, sub-processors, and breach exposure. AI Insights 365 — On-Prem Edition takes the opposite approach: the entire platform runs inside your own infrastructure, and its security controls are designed to support your GDPR, HIPAA, and SOC 2 programs.

An important framing before we begin: software does not make an organization compliant. GDPR, HIPAA, and SOC 2 are obligations that rest with you, the data controller or covered entity. What a well-designed platform can do is provide controls that help you satisfy specific requirements and produce the evidence auditors expect. This article maps the platform's controls to common requirements of each framework so your compliance team can see where the product helps — and where the responsibility remains yours.

Why On-Prem Changes the Compliance Equation

The single most consequential decision for analytics compliance is where the data lives and who can touch it. With AI Insights 365 deployed on-prem:

• Data never leaves your infrastructure. There is no vendor cloud in the data path, no third-party sub-processor handling your records, and no cross-border transfer introduced by the analytics layer.
• The AI can be fully air-gapped. Natural-language-to-SQL and report generation can run against a local Ollama model, so prompts and data never traverse an external API. For environments handling regulated personal data or PHI, this removes a category of risk entirely.
• Credentials stay in-network. The platform connects directly to your databases inside your own network — reaching remote subnets over private routing or a VPN — and stores each credential encrypted with AES-256, so database secrets are never centralized in or exposed to a remote service.

This posture directly addresses the questions that dominate vendor risk assessments — data residency, sub-processor inventory, and the scope of systems that process regulated data — by shrinking the answer to "it all runs here."

The Core Controls

Across all three frameworks, the same set of platform controls does most of the work. It is worth defining them once:

• Data residency / on-prem execution — the platform and its data remain on customer-controlled infrastructure.
• Air-gapped AI option — the AI layer can run locally with no external calls.
• AES-256 encryption at rest — stored secrets are encrypted with a rotatable key.
• Direct in-network database access — the platform connects straight to your databases over your own network (private routing or VPN for remote subnets), so credentials and query traffic never leave your control, and access uses least-privilege, read-only accounts.
• Read-only sandboxed queries — AI-generated queries execute read-only in a sandbox and cannot mutate source data.
• RBAC with least privilege — Admin/Editor/Viewer roles scoped per workspace, with hard isolation between workspaces and organizations.
• AD/Entra SSO and group-mapped access — authentication and authorization are driven by your directory.
• Signed, scoped report embed tokens — shared and embedded reports are constrained to their intended scope.
• Audit trail — per-user create/edit/delete/access events, queryable by org, user, and time.

The sections below show how these map to each framework.

Mapping to GDPR

The EU General Data Protection Regulation emphasizes lawful, secure processing of personal data, data minimization, and demonstrable accountability. The platform's on-prem nature is especially relevant to Article 32 (security of processing) and to the transfer rules of Chapter V.

Because data and the AI layer can remain entirely within your jurisdiction, the platform helps avoid introducing new international transfers — a frequent complication when analytics is delivered from a vendor cloud. The audit trail supports the accountability principle by letting you demonstrate who accessed personal data and what changed.

What remains yours: establishing a lawful basis for processing, honoring data-subject rights, maintaining your Article 30 records of processing, and conducting DPIAs where required. The platform supplies controls and evidence; the program is yours to run.

Mapping to HIPAA

For covered entities and business associates handling protected health information (PHI), the HIPAA Security Rule defines administrative, physical, and technical safeguards. The platform's controls map most directly to the technical safeguards.

Keeping the analytics stack on-prem with an air-gapped AI option means PHI used for reporting does not flow to an external AI service — a meaningful reduction in the surface that would otherwise need contractual and technical safeguards. Read-only query execution helps protect data integrity by ensuring the analytics layer cannot modify source records.

What remains yours: executing Business Associate Agreements where applicable, conducting your HIPAA risk analysis, implementing the administrative and physical safeguards (workforce training, facility controls, contingency planning), and setting policies for minimum-necessary access. The platform helps you meet the technical safeguards; the broader compliance obligations stay with your organization.

Mapping to SOC 2

SOC 2 reports are built on the AICPA Trust Services Criteria, anchored by the Security (Common Criteria) category and optionally Availability, Confidentiality, Processing Integrity, and Privacy. SOC 2 is an attestation of your control environment performed by an auditor — the platform contributes controls and evidence, not the attestation itself.

The audit trail is particularly valuable for SOC 2, where auditors test whether controls operated effectively over a period. Being able to query per-user access and change events by time gives you ready evidence for access reviews and change management. The backup and restore capability — producing portable .orgbak and .wbak archives that can be restored into the same or a different deployment — supports availability-related criteria and your recovery procedures.

What remains yours: defining and documenting your control environment, performing risk assessments, operating the controls consistently, and engaging an auditor for the actual SOC 2 examination. No product can issue your SOC 2 report.

A Shared Responsibility, Made Clearer

The pattern across all three frameworks is the same. The platform reduces risk structurally by keeping data and AI on-prem, and it supplies specific technical controls — encryption, access control, in-network credentials, read-only queries, scoped tokens, and a comprehensive audit trail — that map to named requirements. Those controls help you satisfy obligations and produce evidence.

But the obligations themselves remain with your organization:

• You determine lawful basis, execute BAAs, and define your control environment.
• You run risk assessments, DPIAs, and access recertifications.
• You engage auditors and pursue attestations or certifications.
• The platform provides the controls and the records that make all of that defensible.

Practical Next Steps for Compliance Teams

To put this mapping to work:

1. Inventory the data each workspace will touch, and classify it against the frameworks in scope.
2. Enable the strongest applicable posture — choose the air-gapped AI option for regulated personal data or PHI, and connect every database directly over your own network (private routing or VPN for remote subnets) using least-privilege, read-only accounts.
3. Confirm encryption is enabled for secrets and that your key rotation policy is documented.
4. Drive access from your directory using AD/Entra group mappings, and default users to the least-privileged role.
5. Schedule audit-log reviews aligned to your recertification cadence, and retain exports as evidence.
6. Establish a backup routine using .orgbak and .wbak archives to support availability and recovery requirements.
7. Document the mapping between these controls and your specific framework obligations as part of your control narrative.

On-prem analytics will not, by itself, make you compliant — nothing can. But by keeping your data in your infrastructure and layering precise, auditable controls on top, AI Insights 365 gives compliance teams a strong, defensible foundation on which to build GDPR, HIPAA, and SOC 2 programs.

Where the Frameworks Overlap

Compliance teams subject to more than one framework often duplicate effort, treating GDPR, HIPAA, and SOC 2 as separate projects. In practice, a small set of platform controls satisfies overlapping requirements across all three, which lets you implement once and map many times.

• Encryption at rest answers GDPR Article 32, the HIPAA encryption addressable specification, and SOC 2 CC6.1 with a single control — AES-256 with a rotatable key.
• Access control through least-privilege RBAC and AD/Entra SSO maps simultaneously to GDPR confidentiality, the HIPAA access-control standard, and SOC 2 CC6.1.
• The audit trail serves GDPR accountability, HIPAA audit controls, and SOC 2 monitoring and change-tracking criteria from one queryable source of per-user events.
• On-prem execution with air-gapped AI addresses GDPR transfer restrictions, HIPAA transmission security, and SOC 2 protection from external threats at once, because the data simply does not leave your environment.

Recognizing this overlap lets you build a single control narrative and reuse the same evidence — most importantly the audit-log exports and backup records — across each framework's examination.

A Note on Evidence

Auditors and regulators rarely accept a control's existence on faith; they ask for evidence that it operated. The platform is built to produce that evidence directly:

• Access evidence comes from the audit log, filtered by user and time to show who reached which resources during a review period.
• Change evidence comes from the same log's create, edit, and delete records, supporting change-management testing.
• Recovery evidence comes from your backup routine — retained .orgbak and .wbak archives, and ideally a record of periodic restore tests.
• Access-review evidence comes from documenting each recertification: the period reviewed, the mappings confirmed, and the remediations made.

Capturing this material as part of routine operations — rather than scrambling for it at audit time — is what turns the platform's controls into a defensible compliance posture. The product supplies the raw records; disciplined retention and documentation by your team turns them into an audit-ready story.