Data Governance & Compliance
When an audit asks who could do what, and when, you should not have to reconstruct the answer.
DataFuseAI gives your team three control layers: permission groups that set what each group can do module by module, an audit log that records who changed what — with the old value and the new value — and a private workspace per user, where files stay theirs until they are shared with named Read, Write or Allow Manage access.
Challenges We Solve
These four are the same problem in different clothes: the access decisions are real, but the record of them is not. Permissions get granted in a chat thread, tracked in a spreadsheet, and reconstructed from memory when someone finally asks. The reconstruction is the expensive part — not the control itself.
Reconstructing access after the fact
An audit asks who could edit that engine in March, and who signed off. Your systems recorded that the change happened — not what the value was before it, and not who held the standing to make it. So you rebuild the answer by hand.
Access granted fast, removed slowly
Someone joins a project and has access the same afternoon. The project ends, the role changes, the permission stays. Nobody on your team is confident which of last quarter's grants still need to exist today.
Granting access is itself untracked
The request arrives in a direct message, the approval lives in a reply, and the grant happens in a console. Three places, no single record — so proving a grant was authorised means finding all three again.
No clean line between one person's work and everyone else's
One analyst's saved queries, connection profiles and half-finished pipelines sit in the same space as everyone else's. Nobody can say with confidence whose work is whose, or who can open what.
How DataFuseAI Helps
Three control layers, plus a choice about where the whole thing runs. Permission groups decide what a group can do inside each module. The audit log records every change with its old and new value, and every user gets their own filepath-scoped space that only widens when someone deliberately shares out of it.
Role-based access control groups
You create a named group — Developer Group, say — and tick its permissions module by module: Cluster, Logger, Pipeline, Driver, Dashboard, Query Editor, Connection Profile and more. Each module carries its own Select All. People inherit the group, so nobody ends up holding a permission set only they understand.
Audit log with change history
Every action lands in the log with when, who, category, action, resource and IP address. Open one and you get the field that changed, its old value and its new value — so "what was it before?" is already answered, not reconstructed. The list filters by category and exports.
Workspace isolation and file-level sharing
Each user is auto-provisioned a folder under a Users root, holding their own Connection Profile, Job, Pipeline and Saved Query subfolders. On top of that, any single file or folder carries its own share list — Read, Write, Allow Manage or Remove Access, chosen per person.
Flexible deployment options
Run DataFuseAI fully managed, private-hosted on your own servers with our support, or entirely on-premise. The engine is a separate choice — Databricks, Apache Livy or the DataFuseAI Native Engine — and does not change with the deployment model. Each deployment model is set out in full.
See exactly what each group can do
These are the real screens — the Edit Group screen and the Invite User modal as they ship. Permissions live inside a named group and are ticked one at a time, grouped by module, with a Select All per module. Users do not hold permissions directly — they are assigned to the group, and that assignment happens in the same modal that sends the invite.
Permissions belong to the group, not to the person
A person gets their permissions the moment they are invited
Every change, with what it was before
Every action is recorded with when it happened, who did it, its category, the action name, the resource it touched and the IP address it came from. Open a row and a Log Details drawer breaks it into WHO, WHAT, WHICH RESOURCE, WHEN & WHERE and DETAILS, with a CHANGES table naming the field, its old value and its new value. The list filters by category and exports.
The record exists before anyone asks for it
What it was, and what it became
The same group, in its own audit record
Each user starts with only their own files
Every user is given their own folder the moment they exist — created by System, scoped by filepath, sitting under a Users root. Inside it are their own Connection Profile, Job, Pipeline and Saved Query subfolders. Nothing widens beyond that on its own: sharing a file is a per-person choice between Read, Write, Allow Manage and Remove Access.
One space per person, created automatically
What is inside that space
Widening access is a deliberate act
The default is no access to anyone else's space. Every widening is a named person, on a named file, at a named level — and the group and permission changes behind it land in the audit log as their own entries.
The named controls behind these screens
Compliance is your program, not a product feature. What DataFuseAI supplies is the access-control, audit-log and isolation layer inside it — the kind of controls your team draws on when building toward SOX, HIPAA and GDPR readiness.
Control AC-6, Least Privilege — employ least privilege, allowing only the authorized accesses users need to accomplish assigned tasks — NIST, 2020.
NIST SP 800-53 Rev. 5£14m to Capita plc and Capita Pension Solutions over a 2023 breach affecting about 6.6 million people, with inadequate administrator access controls among the failings — UK ICO, 2025.
UK Information Commissioner's Office€5m to France Travail, where access authorizations had been defined too broadly, allowing advisers to access data on individuals they were not supporting — CNIL, 2026.
CNIL (France)An order requiring Blackbaud to implement a written information-security program covering access controls, multi-factor authentication and encryption — US FTC, 2024.
US Federal Trade CommissionSection 404 requires an annual internal control report from reporting issuers, including management's assessment of internal control over financial reporting, with auditor attestation — US SEC, 2003.
US Securities and Exchange Commission
Key Benefits
You end up with three answers you can give without a search party: who can do what, what changed and what it was before, and whose files are whose. Each one is a record the system keeps on its own — not something your team assembles the week an auditor books a meeting.
Audit-ready by design
The log is written as the work happens, so when the request lands you are reading a record rather than building one. Every entry keeps its actor, its resource, its timestamp and its before-and-after values.
Fine-grained access control
Permissions are set per module and per action inside a named group, then applied to a person at the moment they are invited. Nobody accumulates a private permission set, and the group stays the single place you change it.
Two permission layers, not one
Module-level groups decide what a person may do. File-level shares decide which specific files they may do it to. The two stack, so broad capability never quietly turns into broad visibility.
Isolation by default
Each person's workspace is theirs — their connection profiles, jobs, pipelines and saved queries at their own filepath — until someone deliberately shares something out of it. There is no shared-by-accident state.
Frequently Asked Questions About Data Governance
Data governance is the set of rules and controls that decide who can use your data, what they can do with it, and how that use gets recorded. In practice it lands on three working layers: access control that sets permissions, an audit trail that records changes, and isolation that keeps each person's work separate. The policy is yours to write; the layers are what a platform has to provide.
Access control decides how far a single account can reach. Without it, one compromised or over-scoped login can touch systems it was never meant to. Regulators and standards bodies treat it as basic: NIST names least privilege as control AC-6 (NIST, 2020). France's CNIL fined France Travail €5m after finding access authorizations had been defined too broadly (CNIL, 2026).
RBAC assigns permissions to roles or groups rather than to individual people, then places people into those groups. In DataFuseAI you create a named group, tick the permissions it holds module by module — Cluster, Logger, Pipeline, Driver, Dashboard and others — and assign users to it. Changing what someone can do means moving them between groups or editing the group, not editing the person.
An access control list attaches permissions to a specific object and names who may act on it. RBAC attaches permissions to a group and defines what that group may do across the system. DataFuseAI uses both: module-level permission groups set the kind of work you can do, and a per-file share list of Read, Write, Allow Manage or Remove Access sets which files you can do it to.
Start from least privilege — NIST's control AC-6 sets the expectation that an account holds only the access its assigned tasks require (NIST, 2020). Decide how someone enters a group in the first place; in DataFuseAI the group is chosen inside the Invite User modal, so provisioning and permissioning happen in one step. Then plan the exit, because stale access is what builds up when grants are quick and removals are slow.
An audit trail is a chronological record of the actions taken in a system — who did each one, what it affected, and when. A useful one also records the change itself, not just that a change occurred. DataFuseAI's audit log lists When, Who, Category, Action, Resource, Changes, Description and IP Address. Opening an entry shows the field that changed, with its old and new value.
Responsibility usually sits with whoever owns the data platform — a data lead or platform team, often alongside a security or compliance owner — while the people using the data are accountable for working inside the rules. In a product, that responsibility shows up as named groups with explicit permissions: the group definition is the written form of who is trusted with what. Someone has to own that definition and keep it current.
Start by writing down who may do what with which data, then put it somewhere that enforces and records it. Three control layers do the enforcing: role-based permissions for capability, an audit trail for change history, and workspace isolation so each person starts with only their own material. A framework that exists only as a document is one nobody can prove you followed.
Data residency is where your data physically sits — the country or region the storage lives in — while data sovereignty is whose laws apply to it, which usually follows from that location but is not always identical to it. You influence both by choosing where you deploy: DataFuseAI can run fully managed, private-hosted on your own servers, or entirely on-premise.