The Security Policy Rollout Survival Guide

The Security Policy Rollout Survival Guide

Speakers: Maya Gatski, Founder and CEO, Oblique

Conference: BSides Seattle 2026

YouTube: https://www.youtube.com/watch?v=silvVBIV2pY

Overview

Maya Gatski, founder and CEO of Oblique (an access and group management solution), delivers a comprehensive operational guide to rolling out security policies in enterprise environments. Gatski's background spans product and engineering leadership at Tailscale, software supply chain security at GitHub, and container security and encryption at Google Cloud -- giving her firsthand experience with policy rollouts at organizations of vastly different scales.

The core thesis is that the gap between defining a security policy and having it live in your environment is where most security teams fail, and that gap is filled not with technology but with stakeholder management, communication, piloting, enforcement design, and exception management. Gatski structures the talk around the complete lifecycle: from identifying stakeholders and running pilots, through enforcement strategies ranging from "just tell them" to "make it automatic," to managing both long-lived and short-lived exceptions.

This talk is notable for its practical specificity. Rather than discussing policy in the abstract, Gatski walks through concrete examples -- MFA on SaaS apps, YubiKeys for production access, peer code review requirements, branch protection rules, password rotation policies -- and addresses the real-world complications that arise at each stage.

Background

▶ Watch: Introduction and the prod vs corp environment distinction (0:00)

Gatski draws a critical distinction between production and corporate environments that shapes everything about how policies are rolled out. Production environments tend to be homogeneous (same VMs, same cloud, same hardware), the security team has more authority, and users are generally technical engineers who can handle complex controls. Corporate environments are heterogeneous (mixed devices, mixed OS), the security team has less authority (sales wins when it wants something), and controls must work for everyone from engineers to designers to finance to interns.

This distinction matters because the stakeholders, communication strategies, pilot requirements, and enforcement approaches differ fundamentally between the two environments. A control that works in prod may be completely unsuitable for corp, and vice versa.

Key Findings

▶ Watch: Over-communicate: what, when, why, and how to get exceptions (5:45)

Stakeholder Management: In production environments, key stakeholders include engineering (who want to know how long implementation takes and whether there are libraries or code samples), product (who will weigh security against other tech debt), and the SRE team (who want to know about paging impact and new dependencies). In corporate environments, IT is the primary stakeholder (responsible for implementation but often without the ability to fix things), HR asks about employee impact, finance asks about cost, and legal should be consulted about what controls should not be applied to employee devices.

Communication: Gatski's rule: communicate "way more often than you think you need to, way more often, and in multiple different ways." Every communication should include what is changing, when, and why. The "why" builds trust. Exception request processes must be communicated early and repeatedly.

Piloting: A good pilot has four elements: a representative set of participants (not just the infosec team -- include finance, marketing, design), enough time (at minimum, cover one full cycle of the control -- if it's a 90-day password policy, pilot for at least 90 days), a support channel for escalation and feedback, and clear success criteria. Success for a pilot is simple: you reach a go/no-go decision.

Enforcement Spectrum: Gatski presents an enforcement maturity model from weakest to strongest: (1) tell users they must do it, (2) make it a social norm, (3) make it visible ("80% of your peers are doing this"), (4) make it easy (paved paths, secure by default), and (5) make it automatic (users do not even realize they are in compliance). Each step to the right requires more engineering investment but produces better outcomes. She cites Google's encryption at rest implementation, where the team built encryption into the storage systems so every service built on top had encryption by default without developers doing anything.

Exception Management: Exceptions will always exist. Gatski categorizes them into long-lived (permanent -- e.g., users with disabilities requiring different keyboard tools, demo/test environments) and short-lived (temporary -- e.g., lacking control, current project constraints). Long-lived exceptions should be tracked by reason, grouped, and regularly reviewed but never expired. Short-lived exceptions should automatically expire. Both must be accounted for from the beginning of the rollout design.

Technical Deep Dive

▶ Watch: Enforcement spectrum: from tell them to make it automatic (12:00)

The technical content is operational rather than exploit-oriented, but it is precise and specific. Gatski references concrete controls including branch protection rules, MFA enforcement across SaaS applications, YubiKeys and passkeys for production access, SCIM provisioning, TOTP, domain restriction enforcement, and device unlock policies (PIN length on mobile devices accessing work email).

The Google encryption case study is the most technically illustrative example: rather than mandating encryption at rest across hundreds of services, Google's encryption team worked with storage teams to build encryption directly into the storage layer. Services built on top received encryption by default. Gatski describes talking to engineers who did not even know their systems were encrypted -- "They are. You don't have to worry about it." This is the "automatic" end of the enforcement spectrum.

She also addresses the emerging dimension of AI agents and policy compliance: if AI agents are writing code or making changes in your environment, the enforcement model must account for non-human actors. If you want AI agents to follow your security policies, you need to get enforcement to the "easy" level at minimum.

Demo / Proof of Concept

▶ Watch: Google encryption at rest: invisible security by default (14:30)

No live demo was presented. The talk is structured as an operational guide with concrete examples drawn from Gatski's experience at Google, GitHub, Tailscale, and Oblique. The Google encryption at rest deployment serves as the primary case study.

Defensive Implications

▶ Watch: Long-lived vs short-lived exceptions and gray areas (19:00)

This talk is directly actionable for any security team rolling out policy changes:

• Distinguish between prod and corp environments from the start -- stakeholders, authority, and user capabilities differ fundamentally
• Over-communicate during every phase of the rollout: what is changing, when, why, how to get exceptions, and how to give feedback
• Run pilots with representative users (not just the security team), with enough time to cover a full control cycle
• Build exception management into the design from day one -- assume exceptions will exist
• Move enforcement to the right on the maturity spectrum: from "tell them" toward "make it automatic"
• The person who sets the policy should be the one who enforces it and manages exceptions -- do not delegate enforcement to managers or IT without ownership
• Two success criteria matter: did you meet the security goal, and do your users not hate you?
• Design for AI agents as users of your security policies, not just humans

Key Takeaways

• The gap between defining a policy and deploying it is where security teams fail -- that gap is filled with stakeholder management, communication, and iteration
• Production and corporate environments require fundamentally different rollout strategies due to differences in authority, user capability, and device heterogeneity
• Pilots should be representative, time-sufficient, have a support channel, and have clear go/no-go success criteria
• Enforcement maturity ranges from "tell them" to "make it automatic" -- Google's encryption at rest shows what "automatic" looks like
• Exceptions will always exist; categorize them as long-lived or short-lived and build automatic expiration into temporary exceptions
• The policy owner must also be the enforcement owner -- delegating enforcement without ownership guarantees failure
• Social capital is a finite resource: a rollout that frustrates users undermines your ability to roll out the next policy

About the Speaker(s)

Maya Gatski is the co-founder and CEO of Oblique, an access and group management solution focused on making access self-serve and explainable. She previously led product and engineering at Tailscale, worked on software supply chain security at GitHub, and worked on container security and encryption at Google Cloud. Her slides are available online via the link shared during the talk.