Library · Data Practice OS

Security foundations, the first 90 days

Reference guide · Published · Source reviewed 2026-11-06

The answer: build identity and classification first. Every other tool inherits access from identity groups and inherits handling from classification labels, so nothing else starts until those two exist. Then land the platform skeleton, the one sanctioned code path into the platform, the data-plane and consumption controls, and finally analyst compute and master data.

Source and status. 90-Day Implementation Plan: Data Platform Security Foundations, draft, 5 Nov 2026. The draft is written for Microsoft Fabric, Purview, Power BI, Posit and Profisee. This page keeps its platform-neutral practices and generalises them. The platform is not decided in most organisations: Fabric is not part of Choosing a platform - Snowflake, Databricks, or both or any ADR. The dates, owners and licensing assumptions in the draft are not adopted. Proposed practice, not an agreed decision.

This is Stage 0 of Roadmap and maturity. The principles behind it are in Governance, security and trust.

Sequence

Weeks	Stage	Exit
1-3	Identity and classification. Group model, privileged access, labels, audit, catalogue scans, posture baseline	Groups and labels exist; no tool is built yet
4	Platform skeleton. Dev, test and prod environments under git, deployment pipeline, workspace identity, network decision	Gate 1
5-6	Controlled code path. dbt and Python into the platform under per-environment service identities, with supply-chain controls in CI	First governed run in dev
7-8	Change freeze. Treated as buffer, not plan: catch up on slipped items, and draft the one-page standards	Nothing new scheduled
9-10	Data-plane and consumption security. Fine-grained data access, the BI semantic model with row and object security, DLP in audit mode	Gate 2
10-13	Analyst compute, one MDM domain, operate. Then hand over to the team that runs it	Gate 3 (day 90)

Identity and access

No tool ever receives an individual user assignment. Access goes to groups. Write that down as a standing rule in week 1.
Group naming taxonomy: grp-<tool>-<scope>-<role>, for example grp-sf-registrations-analyst or grp-dbx-licensing-admin. Groups for row-level security use the same pattern (grp-bi-rls-<dimension>). Mirror group names into each tool exactly, with the same casing.
Dynamic groups from HR attributes wherever the attribute exists; static groups elsewhere.
Admin roles only through PIM: eligible, time-limited and approved, never standing. Two documented and tested break-glass accounts.
SSO plus SCIM provisioning from day one, for every tool. Never let a tool keep its own local user model, because leavers then stay active in it.
One service principal per environment, scoped to that environment only. No shared deploy identity across dev, test and prod.
Separation of duties. The IAM lead and the security lead are not platform builders, so access decisions are reviewed by someone who doesn't build.

Classification first

Choose a small label set that maps to your mandated classification scheme (for example OFFICIAL, OFFICIAL: Sensitive, PROTECTED). Decide which label triggers encryption and which triggers stronger sign-in conditions. Publish the labels before any data moves.
Scan the pilot domain's sources into the catalogue in week 3.
Classification, privacy tags and AI permissions are separate records (Governance, security and trust).
Open question: which system is the system of record for classification: the identity vendor's sensitivity labels (Purview, for example) or the data platform's own tags? It is recorded as open in the Decision register. Until it is decided, record the label and the tag together, and test that they agree.

Supply chain and secrets

A private package index as the sole source for Python (and R). Block the public index at the proxy; pip and uv point to the private index by policy.
Lockfiles with hashes are mandatory. Software composition analysis (SCA) runs in CI, for example pip-audit.
A supported-interpreter policy, such as Python 3.12 and 3.13, published and enforced in the template repo.
Every client-secret expiry date goes in a team calendar with a 30-day warning. An expired secret becomes an outage. Prefer workload identity or managed identity wherever the tool supports it.
dbt grants: codified, so warehouse permissions survive rebuilds. Branch protection and required review; CI on every pull request against an ephemeral schema (CI/CD and environments).

Network

Make the private-link decision early, in week 3, before any environment is built. On some platforms, changing it later forces you to recreate items. Record the decision even if it is "no".

Data plane and consumption

Production workspace pattern: admins through PIM only; no members or contributors in production, because change arrives through the deployment pipeline; consumers are viewers, plus fine-grained data roles.
Shortcuts and shares keep the source's security. Data that is referenced rather than copied stays governed where it lives.
Prove viewer-only access through every engine: SQL, Spark and the BI app. A control that holds in one engine and not another is not a control.
Test label inheritance on export with a real test account, not "view as". Export to Excel, PDF and PowerPoint, then check the label and the protection on each file.
BI: dynamic row-level security keyed to groups, object-level security on salary and personal columns, reports published as apps with audiences, and Build permission withheld from consumers.

DLP and posture

DLP from audit to block. Start with one built-in sensitive information type (TFN or ABN) in audit mode. Move to block for that type once you know its false-positive rate.
Check what the DLP engine skips before you sign Gate 3. Some engines skip content that a service identity publishes or owns, and some skip column types or storage modes. Block mode protects nothing there. The Microsoft limits are listed under "Mapping to platforms" below.
DSPM baseline on day 0, compared on day 90. Without a baseline you can't show that posture improved.
Quarterly access reviews on every admin group and every catalogue role group.
Audit logs from every tool to the SIEM: identity, catalogue, data platform, dbt, analyst compute and MDM.
Retention settings on workspaces, dbt artefacts and analyst session storage.
An offboarding runbook: SCIM deactivation plus home-directory archive.

Master data: one domain first

MDM pays off only once sources are catalogued and the platform is stable, so it comes last.

One domain first (customer or asset, say) whose sources are already in the catalogue.
A stewardship workflow (approver, then steward), with history and versioning tested on a test record.
Golden records published back to the catalogue, with lineage.
Prove security inheritance through the BI connector, as a steward and as a reader.
SSO and SCIM like every other tool, with no local accounts.

Phase gates

Three go/no-go gates. A failed gate holds the next phase; phases don't overlap to make up time. Each gate has named signers and written pass criteria (Gate criterion).

Gate	Pass criteria	Signed by
1. Foundations (week 4)	Labels visible in the platform and BI; dev, test and prod under git; zero direct user assignments in any tool; every admin role only via PIM; posture baseline captured	IAM lead, security lead
2. Controlled pipeline (week 10)	Source → dbt → platform → semantic model → app runs end to end; every hop authenticated by an organisational identity; every item labelled; viewer-only access proven via SQL, Spark and the app; DLP policy in audit mode	Data platform lead, BI lead
3. Day 90 (week 13)	Posture improved against the baseline; DLP in block mode for the first type; one MDM domain live with stewardship and catalogue publish-back; analyst users provisioned by SCIM only; quarterly access reviews scheduled; all log sources in the SIEM; the three one-page standards published	Security lead, PMO

The three one-page standards are the workspace pattern, the group naming standard and the label-to-control map.

Out of scope for the first 90 days

Each needs the pilot pattern proven first, or audit history to learn from:

A second MDM domain or a second platform domain.
Insider-risk and adaptive-protection tooling (needs audit history; month 4).
Fine-grained row and column security beyond the pilot (folder and table roles establish the model first).
AI-assistant and DSPM-for-AI tuning (after labels have coverage).
Custom sensitive information types and exact data match (start with the built-ins).

The two failure modes seen most often

Starting with BI because it is visible. The reports work, but the security model is dozens of per-user shares with no labels, and the data behind them is open to every workspace member. BI waits until week 9 for that reason.
Letting tools define their own user model. MDM and analyst tools run happily with local accounts, and will if allowed. SSO plus SCIM from day one costs about a week, and isn't negotiable.

Mapping to platforms

Each row is a capability the plan needs. The Microsoft column is the draft's own design. The platform is not decided in most organisations, and listing it here doesn't select it. Every cell was checked against vendor documentation on 6 Nov 2026. Where the public docs don't settle a cell, it still says verify.

Capability	Snowflake	Databricks	Fabric / Microsoft (platform not decided in most organisations)
Identity: Entra groups via SCIM	SCIM from Entra ID provisions users, and groups as Snowflake roles. Nested groups aren't supported, and over AWS PrivateLink it needs an account in Azure (SCIM with Entra)	Account-level SCIM, or automatic identity management, which also syncs nested groups and Entra service principals (SCIM, updated 3 Nov 2026; automatic identity management, updated 15 Oct 2026). Workspace-level SCIM is legacy and in preview	Native Entra ID groups. Third-party tools still need SCIM: both Posit products and Profisee below
Classification labels	Object tags, and automatic sensitive-data classification through classification profiles, which can apply tags automatically. Needs Enterprise Edition (automatic classification)	Unity Catalog tags, and Data Classification, which tags tables automatically. Classifying views is in beta (data classification, updated 29 Oct 2026)	Purview sensitivity labels applied to Fabric items (apply labels)
Data-plane security	Roles, tag-based masking and row access policies (Governance on Snowflake - Horizon)	Grants, row filters, column masks and ABAC policies (Governance on Databricks - Unity Catalog)	Workspace roles plus OneLake security roles, with row and column security: GA in Fabric engines, preview for third-party engines (docs, see below)
Transform path: dbt	dbt on Snowflake under a per-environment service user, `grants:` in config (ADR-003: dbt as the transformation standard, proposed; grants)	dbt on Databricks under a per-environment service principal	`dbt-fabric`, maintained by Microsoft, with Entra service-principal authentication. It connects to a warehouse; lakehouses use a separate adapter (Fabric setup)
BI: Power BI RLS/OLS	Power BI over Snowflake with Entra SSO, under the user's default role, so Snowflake row access policies apply. ACCOUNTADMIN and SECURITYADMIN are blocked by default (Power BI SSO)	Power BI over Databricks SQL with Entra SSO, in DirectQuery mode only, so Unity Catalog row filters apply. Entra SSO from Power BI to Databricks on AWS is in public preview (Entra SSO for Power BI, updated 11 Sep 2026). Otherwise use RLS in the model	Power BI native: dynamic RLS, OLS authored in TMDL view or external tools such as Tabular Editor (OLS, updated 1 Jul 2026), apps with audiences
Analyst compute	Notebooks in Workspaces under user identity; the original notebooks are now Legacy Notebooks and can't be created in new accounts (notebooks). Posit Workbench also has a Snowflake integration and a Snowflake Native App	Notebooks on Unity Catalog compute in standard access mode, or dedicated access mode assigned to a user. Dedicated compute assigned to a group runs as the group (compute configuration, updated 2 Nov 2026)	Fabric notebooks. Posit Workbench supports Entra OIDC, SCIM and delegated Azure credentials (user provisioning). Posit Connect supports Entra OIDC, SCIM (SCIM) and viewer OAuth integrations for Azure, Databricks and Snowflake (OAuth integrations)
Master data management	Partner MDM over governed tables; golden records back to the catalogue	Partner MDM over governed tables; golden records back to Unity Catalog	Profisee integrates with Purview through an app registration with Collections Admin and Data Curator roles (Profisee deployment README, last changed Aug 2024). Publish-back to the Unified Catalog, and Entra OIDC sign-in: verify, because Profisee's product docs need a login
SIEM	`ACCOUNT_USAGE` views exported to the SIEM: `LOGIN_HISTORY` keeps 365 days with up to two hours' latency (login history). `ACCESS_HISTORY` needs Enterprise Edition (access history)	Audit log delivery as JSON to S3 (audit log delivery, updated 11 Sep 2026). The `system.access.audit` table is in public preview (audit system table, updated 3 Nov 2026)	Fabric and Power BI activity goes to the Purview audit log (track user activities). Sentinel has Microsoft Power BI, Microsoft 365 and Purview connectors (connector reference, updated 28 Jun 2026). Power BI engine logs go to Log Analytics for Premium workspaces only

Microsoft claims checked on 6 Nov 2026:

DLP coverage. Purview DLP for Fabric covers semantic models, lakehouses, warehouses, KQL, mirrored, SQL and Cosmos databases. Its actions are policy tips, alerts and restrict access (DLP for Fabric and Power BI, updated 22 Jul 2026). It evaluates only data in Delta tables, and not every Delta type: it skips timestamp_ntz, binary, struct, array and map columns, and LZ4, Zstd and Gzip-compressed data. It accepts sensitivity labels and the built-in sensitive information types as conditions, but not exact data match or trainable classifiers. Workspaces must be on Fabric or Premium capacity.
Semantic models deployed by a service principal are not evaluated. DLP skips a semantic model when a service principal publishes or refreshes it, or owns it. It also skips DirectQuery, live-connection and mixed-storage models (same page). This plan deploys production through a service principal, so at least one model in the DLP scope must be published or owned by a user, or block mode protects the lakehouse but not the model.
Block (restrict access) status. The Purview page above still labels restrict access preview. Fabric's What's new (updated 27 Oct 2026) lists "DLP restrict access (Generally Available)" in September 2026, and links to that same page. Neither page separates Fabric items from semantic models for this action.
Licensing. The admin who sets up the policy needs Microsoft 365 E5, E5 Compliance or E5 Information Protection & Governance. DLP evaluation also consumes capacity (configure DLP for Fabric, updated 21 Oct 2025).
So, block mode at day 90 is achievable on a feature Microsoft announced as GA, provided the first information type lives in Delta tables or import-mode models that aren't owned or refreshed by a service principal. Confirm the GA label in the Purview portal before Gate 3, because the two pages above disagree.
OneLake security. Row- and column-level filtering is GA in Lakehouse, Spark notebooks, the SQL analytics endpoint in user's identity mode, semantic models in Direct Lake on OneLake mode, Eventhouse and Graph. It is preview for authorised third-party engines and the Table Read API (read secured data, updated 31 Oct 2026). The roles UX went GA in September 2026 (What's new, above). Rules apply only to Delta Parquet or virtualised Iceberg tables; on other table types they block the whole table. Roles don't restrict workspace Admins, Members or Contributors, which is one more reason for viewer-only production. Engines differ: a select * past a hidden column succeeds in Spark but fails in SQL and semantic models (table, column and row security, updated 19 Aug 2026).
Identity per engine. Direct Lake over SQL, and SQL analytics endpoints in delegated identity mode, use the owner's identity, not the user's. Group-membership changes take about an hour to apply, and some engines need about another hour. Role-definition changes take about five minutes (access control model, updated 31 Aug 2026). That is why the plan proves access through every engine.