# One Secure Data Policy > How a four-switch Sigma policy replaced hard-coded workbook access across hundreds of clients with composable organization, agency, division, and brand permissions. - Author: Paul Yu - Role: Senior Analytics Engineer - Employer: Viral Nation - Year: 2026 - Theme: Security - Human article: [https://paul-yu.com/case-studies/sigma-row-level-security](https://paul-yu.com/case-studies/sigma-row-level-security) - Structured data: [https://paul-yu.com/agent/case-studies/sigma-row-level-security.json](https://paul-yu.com/agent/case-studies/sigma-row-level-security.json) ## Evidence | Value | Measure | Evidence level | | --- | --- | --- | | 4 | row-level access dimensions | Repository backed | | 1 dashboard | shared across approved user scopes | Repository backed | | Allow + block | both access paths tested | Repository backed | | Tracked | access grants and checks recorded | Repository backed | ## Situation Access had been hard-coded around individual emails, workbooks, and dashboards. Hundreds of clients, parent brands, partner agencies, and internal users needed different slices. Every new request created manual work and another chance to grant too much or too little. ## Task Create one access model that could express any approved combination of organization, agency, division, and brand without copying dashboards for each audience. ## Action I designed a four-switch Sigma row-level security policy. Teams assign user attributes. Each active attribute filters its matching data field; each intentionally blank attribute leaves that dimension open. The four checks combine into one reusable rule, then impersonation proves both allowed and blocked views. ## Result Clients, parent-brand users, agency partners, and internal teams could share the same reporting product while receiving different row sets. Provisioning became a repeatable team, attribute, test, and audit workflow instead of one-off workbook sharing. ## System flow Approved request → Teams + user attributes → Row-level filter → Impersonated verification ## Technical notes ### Row-level security The dashboard checks every row against the current user. Humans can open the same workbook while receiving different data. ### Four-switch policy Organization, agency, division, and brand each act like a switch. A set value restricts that dimension. An intentionally blank value leaves it open while the other switches still apply. ### Teams and user attributes Teams package reusable access rules. Their attributes carry approved values into the row filter, so a person can inherit a client, parent-brand, partner, or internal scope. ### Positive and negative tests A grant is not complete when approved data appears. Impersonation must also prove that a known unapproved client or brand stays hidden. ## Ownership I designed the switch formula, the team and attribute model, the provisioning workflow, the access tracker, and the live allow-and-block verification process. ## Limitations The formula and workflow are repository-backed. The scale across hundreds of clients is a direct operating observation, not an audited user count. There is no independent penetration test or measured incident-reduction study. A blank attribute grants broad access for that dimension, so the workflow must treat blanks as deliberate security choices. ## Takeaway The scalable unit was no longer a shared workbook or an email permission. It was a reusable policy made from teams, user attributes, four row checks, and proof that blocked data stayed blocked. ## Tools Sigma, Row-level security, Teams, User attributes, Boolean logic, Impersonation