Nine controls, and where each one is explained.
Every deployment includes all nine, configured to your data in the first four weeks. They fall into four areas, and the rest of this page takes each area in turn.
- 01MaskingPersonal values are hashed, removed, cut to a year or partly hidden before the silver layer is written.Personal data
- 02Unmask groupsDynamic Data Masking on the SQL endpoint shows clear values only to a group you name.Personal data
- 03Access controlFive roles from your own Entra ID, restrictive by default and checked on every request.Who sees what
- 04History and lineageEvery row stamped with where it came from, and full slowly changing history behind every figure.Lineage, history and audit
- 05Audit trailAn append-only record of configuration saves, masking changes, alert emails and schema drift.Lineage, history and audit
- 06MonitoringEvery run is compared with the table's own baseline, and results are emailed to people you choose.Monitoring and change
- 07Data qualitySchema drift and failed casts are recorded and flagged as warnings, never passed as a success.Monitoring and change
- 08IngestionA new source is a configuration row, and a failed load is re-read on retry without duplicates.Monitoring and change
- 09CI/CDDevelopment, test and production are deployed through the same pipeline, so changes are repeatable.Monitoring and change
Two ways to protect a column, chosen column by column.
Some values should never leave the source system in clear. Others need to stay readable, but only for a few people. The Accelerator handles both, and during setup we agree with you which applies to each column.
Masked in the silver layer
Applied in the transform chain before silver is written, using a salted hash, nullify, redact, year-only date or partial reveal. The original value is never stored in silver, so nothing built on it can show it: not a Power BI report, a SQL query or an AI agent.
Dynamic Data Masking on the SQL endpoint
The value is stored, but anyone querying it through Power BI, SQL tools or the SQL endpoint sees a masked version. Clear values appear only for members of an unmask security group that you control in Entra ID.
| Column and protection | In the source system | Most users see | Your unmask group sees |
|---|---|---|---|
| National Insurance number Salted hash in silver | QQ123456C | f980c8ac3003… | f980c8ac3003… |
| Email address Dynamic Data Masking | [email protected] | [email protected] | [email protected] |
| Date of birth Year only in silver | 1984-03-14 | 1984-01-01 | 1984-01-01 |
| Mobile number Partial reveal in silver | 07700900482 | 07XXXXXX482 | 07XXXXXX482 |
Masking in the silver layer applies to everyone, your unmask group included. Dynamic Data Masking hides a value only from people outside the group. Hashes are shortened here; the real value is 64 characters. Source values stay in the raw bronze layer so the platform can be rebuilt, and access to that layer is restricted.
Access comes from your Entra ID, and starts at the minimum.
The Accelerator keeps no user list of its own. Everyone signs in with your organisation's Entra ID, and what they can do depends on the role you assign them there. Three separate checks stand between a user and your data.
-
Identity
Your directory decides
Five roles, from MPowerUp Consultant down to Visitor, are assigned in your Entra ID. Someone without a recognised role sees a summary dashboard and nothing else.
-
API
Every request is checked
Each read and save goes through the Fabric API for GraphQL with the user's own token, and that's where permissions are enforced. Hiding a button in the interface is a convenience, and nothing relies on it.
-
Data
Masked columns stay masked
Even with direct SQL access to the platform, a masked column shows its masked value unless the user is in your unmask group.
Three questions an auditor asks, answered from the data.
Where did this figure come from? What did the record look like at the time? What changed in the platform, and when? They're different questions, and each has its own answer recorded by the platform rather than kept in someone's memory.
Where did this figure come from?
Every row is stamped as it moves through the platform, and how each column gets from the source to silver is written down as configuration rather than buried in code.
- Bronze rows record the pipeline run that loaded them, and when
- Silver rows record their source system, source table and when they were written
- The source-to-silver column mapping, with the masking and type rules applied to each column, is held in the metadata
What did it look like at the time?
Every layer keeps full slowly changing history. Each version of a record carries the dates it was valid from and to, so when a number in a report is questioned, you can see the version of the source record it was built from, even if that record has changed since.
What changed in the platform?
Configuration changes go through a preview first: the person saving sees every field that will change before anything is written. The append-only audit table then records:
- Configuration saves to sources, tables, columns and batches
- Each time masking is applied or removed
- Schema drift: new, missing or changed source columns
- Who was sent each run alert
For a visual map, Fabric's own lineage view shows how lakehouses feed semantic models and reports, and Microsoft Purview can show lineage across your wider estate.
Problems flagged as they happen, and changes made the same way every time.
Governance also means knowing when the data is wrong, and controlling how the platform itself changes. These four controls cover both, so problems surface on the run where they happen rather than weeks later in a board pack.
Monitoring
Every run's duration and row count, and any streak of failures, is compared against that table's own recent baseline, so an unusual load stands out. Run results are emailed to the people you choose.
Data quality
When a source adds a column, drops one or sends a value that won't convert, it's recorded and the run is marked as a warning for someone to review. It doesn't pass quietly as a success.
Ingestion
A new source is a configuration row in the same framework, not a new pipeline to write and review. If a load fails, the watermark doesn't move forward, so the retry reads the same window of source data and history doesn't gain duplicate versions.
CI/CD
Development, test and production are deployed through the same pipeline, so a change is reviewed and repeatable rather than a manual edit in production.
What the platform covers, and what stays with you.
No platform makes an organisation compliant on its own. What the Accelerator gives you is controls that are already working, and records that show they're working. This is how they line up with the parts of UK GDPR that people ask us about most.
| Requirement | What the platform does | What stays with you |
|---|---|---|
| Data protection by design and by default Article 25 | Masking rules run inside the data pipeline, and access is restrictive until someone grants more. | Deciding which columns hold personal data and how each should be treated. We work through this with you during setup. |
| Data minimisation Article 5(1)(c) | Personal values are removed, reduced to a year or hashed before the silver layer that reports are built on. | Deciding what you collect and keep in your source systems in the first place. |
| Security of processing, including pseudonymisation Article 32 | Salted hashing, Dynamic Data Masking, Entra ID roles and a restricted raw layer. | Your wider security: tenant settings, devices, staff training and incident response. |
| Accountability Article 5(2) | An append-only record of configuration saves, masking changes and schema drift, alongside the run history. | Your policies, records of processing and data protection impact assessments. |
A summary of how the controls map, not legal advice. Your data protection officer or adviser should confirm what applies to you.
See the controls working before you talk to anyone.
The live demo is the real management interface on sample data. Click through masking, run history and health monitoring in your browser. No sign-up.
Fabric governance, answered.
Does the Fabric Accelerator make us UK GDPR compliant?
No platform can do that on its own. The Accelerator gives you working controls, such as masking, restrictive access and an audit trail, which support data protection by design and the accountability principle. Decisions about lawful basis, retention and what counts as personal data in your context stay with you, and we work through the column-level decisions with you during setup.
Can masked values be recovered?
It depends on the method. Masking applied in the silver layer is permanent there, because the original value is never written to silver. Dynamic Data Masking is applied when the data is queried, so members of your unmask group see clear values and everyone else sees the masked version. Source values remain in the restricted bronze layer.
Who can change the masking rules and access?
Masking rules are configuration, changed in the management interface by people with an editing role. Each change is previewed field by field before it's saved, and the save is recorded in the audit table. Roles and the unmask group are managed in your own Entra ID, so your IT team stays in control of who gets access.
Does this replace Microsoft Purview?
No, they do different jobs. Purview catalogues, classifies and labels data across your Microsoft estate. The Accelerator applies controls inside the data platform itself: masking, access, history and audit on the data it moves. The two work side by side.
Does the Accelerator provide data lineage?
Yes, recorded in the data and its configuration. Every bronze row records the pipeline run that loaded it, every silver row records its source system and source table, and the column mapping from source to silver, with the masking and type rules applied, is held in the metadata. For a visual map, Fabric’s lineage view shows how lakehouses feed semantic models and reports, and Microsoft Purview can show lineage across your estate.
What about Copilot and AI agents?
An AI tool can only use the data it's allowed to reach. Values masked in the silver layer aren't there to find, so a Copilot or Fabric data agent working from the governed layers sees the masked version, just as a report would.
Where is our data held?
In your own Microsoft tenant, as open Delta Lake tables in your OneLake, in the region of your Fabric capacity. There's no proprietary format, so your data stays readable whatever you decide about the Accelerator later.
Is governance an extra cost?
No. All nine controls are part of every deployment, which starts at £20,000, and they're configured within the same four-week delivery window as the rest of the platform.
Bring your data protection questions to a call.
Personal data in finance and HR systems, who should see what, what an auditor will ask for. In 30 minutes we'll show you how the Accelerator would handle your version of each.
A client partner first.