How Modern Companies Are Leaving Behind the Broken Compliance Model

Case study: continuous compliance without the friction. A security-first GRC program powered by verifiable evidence and AI.

Monte Carlo is an AI-native observability platform serving global enterprises. Their customers depend on them for visibility into critical AI infrastructure. Trust isn't a marketing value for Monte Carlo - it's the product. Which means their security program can't be theater.

Like every company scaling fast, Monte Carlo was handed two sets of instructions that don't fit together.

The first: move fast, run lean, build with AI agents and third-party components, ship continuously, do more with a smaller team.

The second: here's your GRC platform. Here are your controls. Here are the tests that verify those controls. Check the boxes. Prepare for your audit.

Monte Carlo looked at the second set of instructions and made a deliberate choice: this wasn't built for us. They partnered with Locktivity to build something that was.

The Closed Compliance Model

Most GRC platforms sell a promise: fast certification, automated evidence, audit-ready in weeks. For a certain kind of company at a certain moment, that promise delivers.

But the model underneath it is closed. The vendor defines your controls. The vendor defines the tests that verify those controls. The evidence is collected on their terms, stored in their system, surfaced to auditors in ways that aren't always visible to you. The frameworks are pre-built. The workflow assumes a dedicated person, or eventually a team, to manage it as you scale.

You're not building a security program. You're subscribing to someone else's.

For companies that build their own infrastructure, move continuously, and treat automation as the default operating model, that's not a compatibility issue. It's a fundamental mismatch. The checklist was designed for a different era of software. It doesn't map to how you actually build.

Alert fatigue sets in. Controls that don't reflect your environment pile up. Tests pass that don't tell you anything meaningful. And somewhere underneath it all, a nagging question: does this program actually reflect our security posture, or does it reflect the platform's template?

Your Infrastructure Is Your Third Parties

There's a deeper problem that the checklist model obscures.

Modern AI-native companies aren't running monolithic stacks with clear perimeters. They're assembling environments from components: cloud providers, AI models, data pipelines, agents, APIs. A cloud hosting provider, an LLM provider, an observability layer, your deployment infrastructure. These aren't internal systems you control, but they are part of your internal infrastructure.

Treating them as anything else is where the compliance fiction begins.

Most GRC platforms treat third-party risk management as an add-on. A questionnaire feature. A checkbox at the end of a vendor onboarding flow. That's not risk management, it's box-ticking.

Real third-party risk starts with understanding how a vendor actually touches your business. What data does it access? What systems does it connect to? What's the exposure if something goes wrong? The risk level follows the use case, not a generic scoring model. A vendor with access to production customer data is a different conversation than one handling internal communications.

From there, you understand the risk. You can focus on risk management - the controls the vendor operates, and the controls you operate.

Third parties are really the foundation of security posture.

How Monte Carlo Built Differently

Monte Carlo is an AI-native observability platform serving global enterprises. Their customers depend on them for visibility into critical AI infrastructure, which means trust isn't a marketing value for Monte Carlo, it's the product. A weak security posture isn't a compliance gap. It's an existential one.

Monte Carlo had used a leading GRC platform. It delivered what it promised: a path to SOC 2, quickly. But as the program matured, the seams showed. Controls that didn't fit how they operated. Tests that weren't transparent about what they were actually verifying. Alerts that trained the team to ignore the program rather than act on it. And audit workflows that surfaced information to third parties in ways that weren't fully visible, a liability for a company whose customers trust them with sensitive data.

The platform was optimized for a finish line. Monte Carlo needed a foundation.

They engaged Locktivity to build a different kind of program. One that fit how they actually operate, not how a compliance template assumes they operate.

The operating model: no GRC hires. An automated security function running SOC 2 and ISO 27001 simultaneously, with hundreds of vendors under ongoing monitoring. The security team operates through the tools they already use. When something needs attention, it surfaces in existing workflows. No new inbox. Tools as enablers, not a platform to manage.

The risk model: Monte Carlo risk-levels every third party based on actual use case and business impact. Locktivity surfaces how each vendor touches their environment, shapes the risk conversation in context, and tracks posture against the frameworks they're accountable to.

The evidence model: Evidence Packs by Locktivity run locally or in GitHub Actions. No secrets stored. No agents with access to sensitive systems. Security configurations tested directly, signed and verifiable evidence pulled back and verified against the controls that reflect how Monte Carlo actually operates. Continuously monitored for drift. Always current.

The result isn't a faster path to certification. It's a program that proves what it claims.

Audit Readiness as a By-Product

The distinction matters.

A program built around the audit produces evidence when the audit requires it. A program built around actual security posture produces evidence continuously, and the audit is just the moment someone asks to see it.

Monte Carlo isn't preparing for audits. They're running a security program that happens to make them always audit-ready. The compliance is the by-product of the program working.

That's what AI-first GRC looks like in practice: controls you own, tests you can verify, evidence that reflects your environment, and risk management that starts where your actual risk lives, in the third-party components your business is built on.

Not a checklist. A program.

Locktivity helps lean security teams build verifiable, automated GRC programs that fit how modern companies operate. Learn more at locktivity.com or explore Evidence Packs at evidencepack.org.