Rob Preta

The through-line

The consistent argument is that security programs built for on-premises estates do not transfer to organisations that live entirely in cloud and SaaS, and that the first thing to break is knowing where your own data is. Preta frames his daily work as evaluating the security program against internal and external threats, and concludes that in an all-cloud environment the constraint is tooling: "we are all cloud-based and all SAS based so what I need is a modern tool set to help secure it" [1]. His posture toward the legacy stack is blunt rather than nostalgic. The instruments he already knew "weren't going to cut it," which left him "always looking for that next best thing" [1].

On data visibility as the first security problem

The insight he describes as the "light bulb moment" is not about threat detection but about location: "being able to identify where all that pii or all that critical data really was hiding in the database that we had" [1]. He is candid that the team had no reliable map beforehand, and treats that as a structural property of the environment rather than an oversight, since in a cloud estate "it's kind of hard almost to find it all" [1]. The value of discovery, on his telling, compounds in two steps. First the data is identified, then the picture of exposure follows: you learn "you have all sorts of vulnerable data or critical data and who's got that access and that really was eye opening to us" [1]. Visibility and entitlement are treated as one question, not two.

On turning discovery into access lockdown

Discovery only matters to him because it drives remediation. The primary user of the platform is his senior staff engineer for infrastructure, whose job is to examine how data is configured, how it is being used, and which applications are reaching it [1]. That feedback loop was fast enough to act on immediately, and the action was to close down permissions: the team "were able to start locking down databases as well so that unnecessary access wasn't uh something that we were just perpetuating out throughout the environment" [1]. The word "perpetuating" carries the point. Excess access is not a static misconfiguration but something an organisation keeps reproducing unless discovery makes it visible.

On rolling out incrementally across the estate

His deployment pattern is deliberate expansion rather than a single sweeping program. "we started small uh but we've actually expanded now to my entire AWS stack and we've started to use them even in our Google workspaces," with the goal of "really identifying that data across all different subsets" [1]. The sequence moves from databases to the full cloud infrastructure to the productivity and collaboration layer, which reflects a view that sensitive data in a SaaS-first company is spread across categories of system that legacy programs treated separately. He also weighs adoption on team reception, reporting that feedback from his staff has been consistently positive [1].

On what modern tooling actually delivers

Preta measures the change in terms of insight rather than features. Compared with the older on-premises and cloud tools he had used, the information available is "almost immeasurable," and he says that in previous environments he "hadn't found anything that even came close and still doesn't" [1]. Crucially, he counts the beneficiary as broader than the security function: the insight accrues to "my team" and "the business," and it is "something that I just can't replicate" by other means [1].

Takeaways

• In an all-cloud, all-SaaS organisation, familiar on-premises security tools "weren't going to cut it," and the gap is what drives the search for modern tooling [1].
• The hardest and most valuable problem is locating sensitive data, because in a cloud environment "it's kind of hard almost to find it all" [1].
• Data discovery should immediately answer the access question too; learning who could reach critical data was the genuinely "eye opening" part [1].
• Excess database access is self-perpetuating unless it is surfaced, so discovery should be followed directly by locking down unnecessary access [1].
• Roll out incrementally: start small, expand to the entire AWS stack, then extend into Google workspaces to cover data across all subsets of the estate [1].
• The primary operator of a data security platform may be an infrastructure engineer examining configuration, usage and application access, not only the security team [1].