Evidence your data rules were followed, ready before the auditor asks.
We are building it to check every night that sensitive data has an owner, is deleted when your policy says, and is reached only through your approval process. When the audit comes, it is designed to turn those checks into evidence for SOX or HIPAA.
We produce the evidence. Your auditor decides. We are building it now, with design partners.
Three checks every night
- Every sensitive table has a current owner
- Data is deleted when your rule says
- Access follows your request and approval process
One pack when the auditor asks, grouped under the controls you are tested against for SOX or HIPAA.
Your platforms report on their own security. Not on whether your rules were followed.
Every audit, your team rebuilds the same evidence by hand from screenshots and exports. A screenshot shows one day. The auditor asks about the whole period.
| What the auditor asks | What it costs you today |
|---|---|
| Does every table with sensitive data have an owner? | Owners move on or leave. Nobody checks until the auditor does, then someone chases names one table at a time. |
| Is data deleted when the policy says? | The policy is written down. Evidence that anyone followed it usually isn’t. |
| Was access requested, approved and ended? | Approvals sit in email and tickets. Access someone gave by hand went through neither. |
| Is sensitive data masked? | Masking rules exist, but nobody reports how many sensitive columns they actually cover. |
| Does one person both change financial data and approve access to it? | Auditors treat it as a segregation-of-duties issue under SOX. Nobody looks until audit season. |
You see the gaps before the audit. The auditor gets evidence they can check.
What the first version is designed to give each of them.
The head of risk and compliance, or the CISO.
- Evidence for the period the auditor names, grouped under the controls you are tested against.
- The gaps, before the auditor finds them: tables with no owner, data kept past its date, and access given outside the process.
- A first draft of the written summary, which someone on your team approves before it goes out.
- No screenshots to collect by hand for owners, deletion and access.
Internal audit, or your external auditor. They decide; we don’t.
- Every finding shows how it was produced, so they can check it themselves.
- Evidence for every day since Data Control Tower was installed, not a single day’s screenshot.
- Grouped by the controls they test, not by our screens.
- Clear about what it doesn’t cover. For security settings, it points to your platforms’ own reports.
Designed to run three checks every night, and build one pack when the auditor asks.
The owner must be a group or someone who still works here. Tables without one are listed by platform and data area.
Each dataset with a retention rule is compared with its real age. Every deletion we can see is recorded: what, when, and which rule or job. Where a platform keeps no record, the pack says so.
It covers every access change and who made it, and access given by hand outside the process. It also covers how many sensitive columns are masked. With Data Access Concierge, it also covers each request, approval and end date.
It flags anyone who does both, using the same access records.
The checks, grouped under the controls you are tested against for SOX or HIPAA, for any period since installation. You get a document for the auditor and a page in Data Control Tower.
The same checks, organized for the regulation you answer to.
The checks don’t change between regulations. Two things do: which data is in scope and how the pack is organized.
For HIPAA, that’s patient health data. For SOX, it’s the data behind your financial reporting.
We choose the controls with you during setup, from the ones your auditor tests.
Each regulation is sold on its own. Others can be added as new mappings of the same checks.
Built on what Data Control Tower already collects.
It’s a module of Data Control Tower and runs in that installation, in your own Azure. If you already have Data Control Tower, the module is added to it, not installed as a second copy.
What it reads
| What | Where it comes from |
|---|---|
| Who holds what, and every access change with who made it | From Data Control Tower, every night. |
| Owners from your catalog, and leavers from your HR file | From Data Control Tower. |
| Requests, approvals and end dates | From Data Access Concierge, if you use it. It covers Amazon Redshift and Databricks. Each request is kept for the whole period only if its Entra audit log is exported beyond Entra’s 30 days. |
| Which columns are sensitive | From your platforms’ own tags, or from our data profiling. |
| Retention rules and deletion records | From a retention register we write with you, plus each platform’s deletion history. |
AI, with a person in charge
AI drafts the plain-language summary the auditor reads. For example, it might say which owners left during the period and how quickly they were replaced. Someone on your team approves every draft before it goes out.
What each platform gives us to work with
| Amazon Redshift | Databricks | Snowflake | |
|---|---|---|---|
| Ownership | Every table has an owner | Every object has an owner, which can be a group | Contacts, which can be a distribution list |
| Retention rule | None built in. We report each table’s age against your rule; your own jobs do the deleting | Auto-TTL expires rows, managed tables only | Lifecycle policies expire rows |
| Deletion record | Your own jobs’ logs, if they keep them. Checked with you in setup | Auto-TTL history (Public Preview) and table history | Lifecycle policy runs. Not yet confirmed as audit evidence |
Redshift has no setting that deletes rows by age, so the evidence there depends on the deletion jobs you already run. The pack says so.
What your security and audit teams will ask
| Your security and audit teams will ask | The answer |
|---|---|
| Does it make us compliant? | No. It produces evidence. Your auditor decides. |
| Can it change our data or settings? | No. It reads your platforms and never writes to them. It doesn’t set or enforce retention. |
| Where does it run? | Inside your Data Control Tower, in your own Azure subscription. |
| Does it repeat our security-posture reports? | No. Platform settings reports stay where they are, and the pack points to them. |
| How far back does the evidence go? | On Amazon Redshift and Databricks, access changes are tracked from the day Data Control Tower is installed. Snowflake keeps a year of history, so during its first week Data Control Tower fills in the 90 days before install, and older days can be loaded on request. Redshift keeps 7 days of query history unless its audit logging to S3 is on. We confirm what yours keeps during setup. |
| Who approves what the AI writes? | A person on your team, before anything goes to the auditor. |
Build it with us, against your next audit.
The Governance Evidence Pack is in early access. It runs on Data Control Tower, available today on Microsoft Marketplace for Amazon Redshift, Databricks and Snowflake.
We’re looking for design partners who answer to a SOX or HIPAA audit for data on any of those platforms. You tell us what your auditor asks for, and we build the first version against it.
Pricing isn’t published yet.
What you need, and when it isn’t for you
You need
- Data Control Tower, already installed or installed alongside this module.
- Data on Amazon Redshift, Databricks or Snowflake, or any combination.
- On Snowflake, Enterprise Edition, which records which tables people read.
- Sensitive data already tagged in your platforms or catalog, or tagged with our help.
- A written retention policy, which we turn into a register with you.
- A SOX or HIPAA audit that covers this data.
- Optional: Data Access Concierge, for Redshift and Databricks, which adds each request, approval and end date to the access evidence.
It isn’t for you if
- You want a product that declares you compliant.
- You want retention set or enforced on your platforms. That is separate service work; the pack only gives evidence of it.
- You want evidence about security settings. Your platforms’ own reports cover that.
- Your data is in Power BI or Microsoft Fabric. That isn’t in scope.
- You need a regulation other than SOX or HIPAA right now. Ask us anyway.
What leaders ask us first
Will this make us compliant?
Our platforms already produce compliance reports.
Which platforms does it cover?
Do we need Data Access Concierge?
Can we buy it without Data Control Tower?
Redshift doesn’t delete data by age. What then?
What about GDPR?
Stop rebuilding the audit file by hand.
Tell us what your auditor asks for. If it’s a fit, you help shape the first version.
Data Meaning is an independent consultancy. Amazon Redshift, AWS, Azure, Databricks, Snowflake, Microsoft Entra, Power BI and Microsoft Fabric are trademarks of their respective owners.