Some compliance shortcuts save time. Others cost you later.

Every compliance program takes shortcuts. A scope trimmed to fit a small team. A claim simplified for a trust page. A gap left open with a plan to close it later. 

Most are defensible on the day they’re made. The trouble starts when nobody goes back to check if they still hold six months later, after a new vendor, a new region, or a new AI feature has quietly moved the ground underneath them. 

That’s when a shortcut turns into what compliance and security teams call “compliance theater.” So how do you tell a shortcut that’s still holding up from one that’s already become a liability?

That was the question at the heart of Scrut's recent webinar, The Compliance Theater Reckoning: Shortcuts That Cost You Later. We were joined by Michael Argast (Co-founder and CEO, Kobalt.io) and Mackenzie Thomas (GRC Manager, Sensiba LLP), who worked through a composite company's live case in real time.

We opened with a poll before either of them spoke: What most often turns an ordinary compliance gap into compliance theater? 

The responses pointed to a common problem: no one checks whether the final compliance claim reflects reality. This option received 30% of the votes, followed by policies, evidence, and external claims that remain unchanged as the business changes (25%) and incentives that reward “clean” results over accurate reporting (25%). A temporary workaround becoming routine and never being reassessed received 20% of the votes. 

Seven lessons on spotting and preventing compliance theater

To help us make things more interesting and understand how compliance theatre can creep up on an unsuspecting team, we took the help of a composite case file in which we asked our panelists to figure out what would have ticked them off when looking at it from the perspective of a security leader and an expert auditor. 

The scenario involved a US-based B2B SaaS company with around 200 employees and 500 customers. Its AI customer service product could access account data and take approved actions in customer systems.

The company had received its first SOC 2 Type 2 report for 2025. It was now supporting four active enterprise reviews, with audit fieldwork starting in ten weeks.

A four-person security and GRC team ran the program. Michael considered that a meaningful investment for a company of this size. His attention went to what had changed and whether the program had kept up.

1. Apply more rigor where the risk has changed

As Michael Argast mentioned, the headcount isn’t the focal point. What’s critical is to ask where a lean team should apply more rigor and where it's fine to ease off.

An AI service that summarizes a support case and one that can issue a refund need different safeguards. The second can move money.

For a workflow that can take actions, examine:

• Permitted actions: Can it edit records, delete information, issue payments, or change access?
• Identity and scope: Whose credentials does it use, and which customer accounts can it affect?
• Approval boundaries: Which actions require human approval, and can execution bypass that approval?
• Operating records: Do logs show the requested action, authorization, and actual result?
• Containment: Can the team revoke access, stop execution, and reverse changes where possible?

OWASP’s 2025 guidance on excessive agency supports this approach: restrict available functions and permissions, require approval for consequential actions, and enforce authorization in downstream systems. A prompt telling an AI system what it may do is insufficient access control.

Michael also identified work that could reasonably receive less attention. Where a thorough vendor assessment already exists, and the relationship remains stable, a focused follow-up may be appropriate.

Before reducing the review, check what “stable” means. Has the vendor gained access to different data, introduced an AI feature, changed its processing arrangements, or become essential to production? Any of those changes may invalidate the reason for a lighter review.

2. Last year’s SOC 2 scope does not automatically describe today’s business

The company's clean 2025 SOC 2 Type II report sat in the case file like a green light. Mackenzie treated it as a starting point, not a verdict.

A SOC 2 Type 2 report addresses a defined system, control design, and operating effectiveness over a specified period. It also includes the auditor’s tests and their results. Its scope, opinion, and exceptions need to be read together.

The report remains evidence about that period. A later product change does not automatically erase its historical value. But the report cannot, by itself, establish that a new connector, production region, or AI workflow is adequately controlled.

This is a more useful distinction than saying that a report is either "valid" or "outdated." Some conclusions may remain relevant. Others may no longer answer the customer’s question.

• Does the product still use the same systems and providers?
• Have the categories of customer data or permitted actions changed?
• Do the controls cover the current employee, contractor, and system populations?
• Are the commitments being made to customers still within the report’s scope?

On AI changes, Michael distinguished routine model updates from new capabilities or connections. That distinction is useful, but a small version-number change alone does not establish low risk. Review the changes relevant to the deployment, including tool use, data handling, and behavior under untrusted input.

Put these checks into the workflows where changes originate (procurement, product releases, infrastructure changes, and control handovers). The next audit should not be the first time the compliance team hears about them.

3. Growth can change several parts of the compliance program at once

Since the company's last audit, a lot had shifted at once: control owners had been reassigned, the contractor and employee population had grown, a new secondary production region had come into scope, and the vendor footprint had expanded.

Of all these changes, expansion into the EU most significantly changed the assumptions underlying the company’s existing compliance setup.

Michael recommends treating this kind of accumulated change (new regions, new owners, new vendors) as a trigger to reopen the whole control set, not just add one new checkbox for whichever change is most visible.

4. Evidence must match the claim

One of the clearest lessons from Michael and Mackenzie was that compliance does not require every control to be perfect. It requires the company to be accurate about what is working, what is still open, and what its evidence can actually support.

Mackenzie made the point from an audit perspective: an untested change, an overdue activity, or an incomplete control can still be handled responsibly if the limitation is visible and there is a clear plan to address it.

Michael drew the harder line at the claim itself. If a company says a control operates in a certain way, and the evidence shows otherwise, the problem is no longer just the control.

The most important distinction worth carrying into day-to-day compliance work is that you do not make the claim broader than the evidence.

A useful check before publishing any trust-page statement, questionnaire response, or control status is: "What would we have to show someone tomorrow to defend this exact claim?" If the evidence supports a narrower statement, use the narrower statement. An honest limitation is usually easier to fix than a credibility problem.

5. Trust-page claims need their own owners and review triggers

A trust page can be accurate when it is published and wrong six months later without anyone deliberately misleading a customer.

That is why Michael argued for event-driven review, not just a quarterly or annual content check.

Those are useful triggers because they can change what is actually true. Even something as small as moving an AI workflow from read-only to read-write access can materially change the risk behind an existing security claim.

That also addresses the accountability problem Mackenzie raised:

They tie trust-page reviews to specific business and technical changes, such as new vendors, integrations, AI workflows, permissions, data flows, or regions. They also assign a named owner to each important claim, so someone is responsible for checking whether the evidence still supports what customers are being told.

The hot take round: Where the panel drew the line

The webinar closed with three statements designed to test how far the panel would go on shortcuts. The interesting part was not that Michael and Mackenzie mostly agreed. It was what each of them needed to see before calling a shortcut defensible.

Statement 1: “Policy, training, and an approved AI tool are a defensible temporary response to shadow AI while technical monitoring is being put in place.”

Michael was comfortable treating policy, training, and an approved AI tool as a temporary response while better monitoring is being built. His reasoning was pragmatic. For many companies, even that is a meaningful step up from having no control at all.

Statement 2: “If a reliable automated control test evaluates the full population, manual sampling the same items adds little additional assurance.”

Both Michael and Mackenzie were comfortable relying on an automated control test that checks the full population, provided the test itself has been validated first.

Michael put it simply:

“The keyword, of course, on this card is reliable. I need to validate it's reliable. Once I validate it a few times, I'm gonna focus my energy in other places.”

That is the part worth keeping. Automation should remove duplicate checking, not remove skepticism.

If the integration is misconfigured, the source data is incomplete, or the test is looking at the wrong population, automation can produce a very convincing wrong answer. Once you've checked the source, logic, and output, there is little value in repeatedly sampling the same items by hand.

Statement 3: “A major product or AI model change should make existing security assurance outdated, even if the audit report or certificate is still formally valid.”

Both panelists agreed that a major product or AI change can make existing assurance less useful, even while the report itself is still formally valid.

Michael drew an important distinction. A small model-version change may not materially alter the risk. New connectors, broader permissions, read-write access, or more autonomous behavior can.

“The capabilities of these AI platforms are changing so fast that the odds of your AI platform remaining stagnant in a 3-month period, let alone a 12-month period, is almost zero.”

Not every shortcut is the problem

The session closed on a question meant to catch people off guard: are there any good shortcuts?

Mackenzie pointed to AI-assisted first drafts, useful for a first-year program building process docs from nothing, as long as the team still checks the output against how the company actually operates. Michael went further:

He pointed to OWASP's risk lists the same way: a shortcut worth taking, because it means not building AI risk analysis from scratch.

A good shortcut saves work without weakening the basis for the conclusion. A bad shortcut skips the checking that makes the conclusion trustworthy.

Ask yourself these questions before making compliance claims publicly

At the next compliance review, choose three consequential statements already being used by customers or leadership. For each, ask:

1. What exactly are we claiming, and for which systems, people, and period?

2. What operating evidence supports that statement?

3. What has changed since the evidence was produced?

4. Which limitations would matter to someone relying on the claim?

5. Who can confirm the statement, correct it, or stop its use?

Each review should end with a decision. Check that the claim is supported as written; it needs a qualification; or it should be withdrawn while the underlying issue is addressed.

That leaves room for sensible simplification, historical evidence, and work still in progress. It also makes the boundary testable, i.e., a planned exercise remains planned, an untested system remains untested, and an automated result applies only to the population and conditions it actually evaluated.

Watch The Compliance Theater Reckoning on demand for the full discussion on where reasonable shortcuts stop being defensible, how stale evidence and changing systems can quietly distort the compliance picture, and what Michael Argast and Mackenzie Thomas look for before trusting a control or claim.