← Back to blog

We Passed Google's CASA Security Audit

Simon Kihlberg Wallström • • 6 min read •
security casa building-in-public oaiz

If you’ve been wondering what I’ve been up to the last couple of weeks: we just completed Google’s Cloud Application Security Assessment (CASA) Tier 2 for OAIZ.

But nobody knows what CASA is, and neither did I before I learned that we needed it.

Short version: OAIZ workflows need deep Gmail access. Reading messages, managing threads, working with labels. Google calls these “restricted scopes.” And if you want them, you have to pass CASA. No exceptions.

Longer version: This post covers what CASA is, why we needed to pass it, what it took, and what it means for our customers and other founders considering the same path.

What is CASA?

It’s Google’s mandatory security audit for apps that want restricted access to user data. You pick an approved third-party lab, they test your application against OWASP ASVS (the global standard for application security), and they verify your architecture, controls, and operational practices.

For customers, it means: “Google looked at this app’s security and decided it’s trustworthy enough for your inbox.”

For us, it meant: “Let’s validate that the security foundation we’re building actually holds up under external pressure.”

We did this early because the product demanded it. We were already building security-first with infrastructure as code, data classification in code, and observability baked in. CASA wasn’t the goal. It was the proof. I learned from previous roles that getting external validation early beats scrambling later.

The Prep Work

This kept me occupied for multiple weeks, but the actual process with Google and the external auditor was rather quick.

The CASA questionnaire lets you pick your scope. We prepped both web + api, but only submitted web for the actual review. That gave us 72 requirements to satisfy.

I worked through it in phases:

  1. Progress tracking: Dumped everything into Google Sheets with a progress tracker. Used Gemini to understand each requirement and figure out what proof we needed: docs, screenshots, diagrams, code references, test cases, live demos.

  2. Gap analysis: Went section by section with Claude in my IDE to identify gaps. Priority one: catch any actual dev work needed as early as possible.

  3. Proof collection: Started collecting evidence and fixing gaps. AI helped a lot here (is this what Vanta does?), but I had to prompt-fight to get good examples from our actual codebase instead of generic best practices.

  4. Self-scanning with ZAP: Google used to accept self-scans verified by labs. Not anymore. You need third-party scans now. But the CASA ZAP toolkit is still incredibly useful for catching issues before the audit. Getting ZAP to play nice with our PWA (handling login, sessions, the full flow) was tricky. We eventually got it running in CI. Best results came from scanning prod (always test in prod, right?) to validate the full stack: Cloudflare WAF → GCP LB → API.

In hindsight we might have been over-prepared, but I have scars from previous security audits.

Google’s Verification

Google requires verification of your brand and data access justification. They want to understand who you are and why you need the scopes you’re requesting.

From starting the formal GCP application to having both Google’s review and the TAC Security audit complete took 8 days total. The rhythm was 1-2 emails per day: clarifications, evidence, proof of fixes.

TAC Security Review

Once approved by Google, you complete the external security review with an approved lab. The actual engagement time with TAC Security, from initial scan to clean result, was less than 48 hours.

We chose TAC Security from Google’s list of approved labs. The process was straightforward:

  • Everything ran through a portal: scope, progress, findings, evidence uploads.
  • Mix of automated scanning and human review.
  • Communication was clear, timely, and professional.

The initial scan found:

  • 4 Low severity issues.
  • 8 Informational findings.
  • 0 Medium, High, or Critical issues.

Most findings were around headers and edge configuration:

  • Content Security Policy tuning.
  • CORS rules refinement.
  • Cache control headers in specific paths.
  • Minor consistency tweaks around security headers.

The main challenge was understanding how Cloudflare (our CDN) interacted with our headers. Making sure we weren’t accidentally overriding or being overridden upstream.

The rescan came back clean. We uploaded final evidence, had a short follow-up discussion, and received our CASA Tier 2 certification.

Final score: 9.7 out of 10. Zero critical, high, or medium findings. All minor issues patched and re-validated in under 48 hours.

My main “oops” moment: I hadn’t rerun the ZAP scanner after our final cloud migration pieces landed. The issues were minor, but they should have been caught earlier. Lesson learned: run your scans after major infrastructure changes.

What I’m Quietly Proud Of

We definitely improved things during CASA. You always do. But the thing I’m most proud of is:

We didn’t have to improve that much to pass.

We’re a small, fast-moving startup. Yet when an independent, Google-approved security lab took a hard look at our stack and practices, there were no critical or structural issues. Just “you should tighten these” items.

That’s not an accident. Between my years as a security champion and going through ISO 27001 at Telavox, plus my three co-founders coming from running a security startup, we had security thinking baked into the team from the start.

CASA didn’t give us a security mindset. It confirmed we already had one.

Everything as Code

If you’re considering CASA or any security audit, here’s what made the process smooth:

Everything as code.

Infrastructure as code. Data classification in code. Policies as code. Documentation as code. Our entire ISMS lives in git.

When everything lives in repositories with version control, collecting evidence isn’t scrambling through wikis and screenshots. It’s pointing to commits, pipelines, and automated tests. Every security policy goes through code review. Every change has a clear track of who, how, when, and why.

CASA asks “prove this policy exists and is enforced.” We point to the repo, the commit, the test that validates it. Done.

Take data classification as an example. Our database models carry metadata about classification level, purpose, and handling requirements. When you add a new table or column, you must declare its classification. It’s part of the code that gets compiled and shipped, instead of external docs that go stale immediately.

But the real benefit isn’t just audit prep. It’s that AI coding tools can find these policies and keep them in context. Same policies for AIs as for humans. They read the security requirements from the codebase and apply them automatically.

This isn’t CASA-specific. This works for any audit, any compliance framework, any time you need to prove “we do what we say we do.”

CASA forces you to prove things, so if your proof already exists in code, you’re already done.

CASA Tier 2 isn’t the finish line for OAIZ. It’s the baseline. But it means we can now focus fully on building the product, knowing the security foundation is solid.

Going through CASA yourself? Have questions about the process? Find me on LinkedIn or X. Happy to share what we learned.