Scaling lessons from Google’s FedRAMP program to a multi-framework CISO seat

Drew Gutstein has fixed compliance that was breaking at nearly every scale it can break at. He spent nearly five years building and running Google’s FedRAMP program. He then joined Hudson River Trading (HRT) in 2023 to build its security governance function from the ground up, moving into the CISO seat the following year, where he juggled obligations across NIST CSF, DORA, SEBI-CSCRF; roughly a dozen regimes overall. He’s since moved on from HRT to build his own venture, Gutstein Security Works, where he is building bespoke, automated cyber controls for complex business environments. We caught up with him mid-build to talk through the lessons that only someone who’s sat in all three seats (CISO, security engineer, and regulatory liaison) can offer: Why compliance breaks the same way at every scale, and what actually fixes it.

We spoke about what breaks first when compliance stops being manual, why insider risk is quietly getting worse, and why nobody has actually solved third-party risk management yet.

AI is expanding insider risk, not just external risk

Ask Gutstein where the next wave of risk is coming from, and he points to developer endpoints and how AI is changing the insider-threat equation in two ways at once. First, AI systems are themselves a target: “The usage of AI within an organization creates this huge attack surface for what’s effectively phishing attacks,” he said. An agent can be manipulated the same way a person can be tricked into clicking a bad link. Second, AI is now writing and committing code directly, and if that code gets checked in and implicitly trusted the way human-written code usually is, it can end up running in production—or worse, in a company’s CI/CD pipeline—before anyone catches the problem.

His recommendation: treat developer environments with far less inherent trust on both fronts. “Keep developer endpoints away from everything,” he said. “This is where the supply chain attacks originate.” He also wants to borrow a practice from open source wholesale, requiring internal code changes to go through independent review before they ship, the same way a maintainer reviews a pull request from a stranger. “We already have a really mature way of safely allowing people edit code that they don’t own. It’s called open source,” he said. His point: open-source maintainers never trust a contribution just because of who submitted it. Every change gets independently reviewed before it’s merged, whether it comes from stranger or not. Companies, by contrast, usually extend automatic trust to code from employees (and now, their own AI agents), even though that code carries the same risk. Drew hasn’t seen a single company import that open-source discipline internally yet, despite how obvious the fix looks once you say it out loud.

Compliance at hyperscale

At Google, Gutstein managed FedRAMP compliance across more than 33 million virtual machines and millions of containers, a scale where the program’s spreadsheet-based approach broke down. FedRAMP requires monthly vulnerability reporting, and and at Google’s scale, the numbers simply didn’t fit in a spreadsheet. That scale, therefore, that broke the format the program expected reports to arrive in. “Imagine a spreadsheet with 33 million machines multiplied by countless detections on it. You can’t put it in a spreadsheet. It doesn’t fit,” he said, a mismatch he chalks up to how fast hyperscale outpaced the tooling everyone was using, regulators included.

That gap pushed Gutstein to work on OSCAL, a NIST-backed standardized format for control data. “Think of it as the XML version of your security plan PDF,” he explained. The whole idea was about making evidence machine-readable rather than manually assembled. He also represented Google on the Cloud Service Provider Advisory Board, pushing cloud vendors to speak with one voice to FedRAMP regulators on how compliance should actually be measured, rather than each pushing conflicting asks that would stall FedRAMP from evolving.

Scale created bottlenecks internally, too. Google’s core infrastructure came with built-in security, but GCP didn’t. Extending real scanning coverage to GCP meant pulling in Google’s internal scanning team that had only ever scanned Google’s own infrastructure, never GCP’s customer-facing products, and getting them to take this on required sign-off all the way up to the CEO of Google Cloud. Even after winning that support, capacity fell far short: the target was 40 products scanned that quarter; the team could actually get through two.

One structural fix he still admires came from a competitor. Microsoft built a “change-type authorization” that lets new Azure products reach the FedRAMP marketplace in weeks instead of the roughly one-year timeframe everyone else takes. “What Microsoft figured was to audit their SDLC process so that the government can just accept each release, and yes, the process itself gets periodically checked by auditors,” he said, but they still effectively save a lot of time. “You don’t have to be Microsoft to do that,” he says while also admitting that it’s hard to build that kind of system and get it off the ground.

Third-party risk management still isn’t solved

Gutstein is unusually direct here: “TPRM is just not figured out yet,” he says. At HRT, his team ran an informal study comparing news-driven breach alerts with notifications from their formal third-party risk system. The finding was uncomfortable: “It took a lot longer to get the alert from the third-party risk system, and there did not seem to be any correlation between the risk score and the likelihood of being attacked.”

Part of the problem, he thinks, is that the discipline still relies almost entirely on self-reported paperwork. Questionnaires create the appearance of diligence without necessarily reducing risk and can be actively misleading, given documented cases of fabricated compliance reports. He applies same approach that pushed him toward open-source-style code review for internal code to the vendor ecosystem too too, and thus draws a distinction that most TPRM programs skip: Open-source and subcontracted code deserve a different trust model versus vendor software, not a single blanket policy. Bottomline: all code gets thoroughly reviewed, and reviewed differently depending on the risk it actually carries.

His sharpest point is about where the real vendor governance bottleneck bottleneck sits. To avoid the review overload that creates roadblocks and pushes teams to route around the process entirely, he suggests every new tool or vendor request should get one question before it ever reaches security. “The most important question in third-party risk management is: Do you really need it? And if the answer is a little bit, you probably don’t,” he said, arguing procurement is where tools should get filtered out before they ever reach a security review queue.

On the tools that do make it through, he sees TPRM’s automation heading toward newer tooling that consolidates SaaS connectors into a single integration layer, replacing static, self-reported questionnaires with a more continuous signal. These tools plug directly into a company’s systems (Okta, cloud platforms, etc.) via APIs, pulling evidence in real time instead of someone manually exporting and uploading a spreadsheet.

Operating under a dozen regulatory regimes at once

The shift from a federal program to a multi-framework CISO role introduced Gutstein to a different complexity: overlap. At HRT, he tracked obligations across NIST CSF, DORA, SEBI-CSCRF, and others simultaneously. Frameworks, he says, are increasingly converging around the same underlying control language, even as new ones keep arriving. His approach was to map controls across regimes for equivalence, using automation to reuse evidence rather than re-proving the same control multiple times.

The bigger shift, he argues, is about timing: “When you have a dozen regulators, and audits are happening concurrently all the time, you have to be already prepared all the time. That’s why you need continuous compliance, continuous security.” He’s also candid about the competitive upside: “If I do a really good job and raise the bar for everyone else, then great”

The Common Thread

Across three roles—CISO, security engineer, and regulatory liaison—Gutstein keeps arriving at the same conclusion. “This is where I’m so passionate about automation,” he said, “because that’s really where you get that benefit, where you’re able to take the security load away from the people who really don’t have any business doing it.” Governance, in his view, isn’t a paperwork exercise. It’s a design problem about human behavior, and the fix is almost always the same: Automate the evidence, prioritize by actual risk, and stop mistaking activity for security.