Security

The future of GRC is technical. As cloud systems grow more complex, companies need controls that scale. This post explores how Compliance as Code helps GRC teams move faster, stay accurate, and work directly with engineers.

The role of GRC is changing. Today’s SaaS companies need more than policy writers—they need GRC engineers. Here’s why.

A leadership philosophy shaped by lacrosse, Auth0 values, and real-world security work.

Introduction PCI DSS 4.0 introduces Requirement 11.6.1, a new expectation to secure the client side of e-commerce environments. This isn’t a minor update. It is a hard reality check where organizations must detect unauthorized changes directly in consumers’ browsers. Traditional server-side protections are no longer enough. What PCI DSS 11.6.1 Requires Requirement 11.6.1 mandates that organizations: Implement mechanisms to detect and alert on unauthorized changes to payment page content and scripts as they load in the consumer’s browser. Specifically, address client-side security, where the user interacts with the page — not just what resides on the server. Evaluate these controls either continuously or at least once every seven days, unless a targeted risk analysis justifies an alternate frequency. Simply, companies must now actively monitor what customers see and interact with, not just what was deployed from their servers. ...

A Little History Before PCI DSS, every credit card company had its own security program. Visa had CISP, Mastercard had SDP, Amex had DSOP — and it was a mess. Merchants didn’t know which rules to follow. Security was inconsistent. Fraud was exploding. In 2004, Visa, Mastercard, Amex, Discover, and JCB finally came together and said: enough. They formed the PCI Security Standards Council (PCI SSC) and created one standard: PCI DSS — the Payment Card Industry Data Security Standard. ...