If your app reads a user's Gmail, Drive, or Calendar beyond the basic scopes, Google will not simply let you ship. You enter OAuth verification, and for restricted scopes that means CASA — the Cloud Application Security Assessment, run through an independent lab.
We went through it for Dioveo, which needs restricted Gmail scopes to read and download attachments. Most of what is written about CASA is either Google's own documentation or a vendor selling you a shortcut through it, so here is the practitioner's version.
What CASA actually is
CASA is an assessment against the OWASP Application Security Verification Standard. Google does not run it; an accredited lab does, and Google consumes the result.
There are tiers. Most apps land in a self-scan plus a verification review: you run an approved scanner against your application, submit the results, remediate what it finds, and answer a questionnaire about your practices. Higher tiers add manual penetration testing.
The important thing to understand early is that it is two separate reviews wearing one name. There is a security review — the ASVS controls — and there is a scopes and privacy review, where Google asks whether you genuinely need the access you requested and whether your privacy policy and in-product disclosures match what you actually do. Teams prepare heavily for the first and get held up by the second.
What it asks for
Justify every scope. For each one, why the narrower alternative does not work. If a metadata scope would do and you asked for full read, expect to be sent back. We scoped Dioveo down twice before submitting, which cost us a feature and saved us a round trip.
Prove the data handling you claim. Where the data goes, how long you keep it, who can reach it, and what happens on deletion. Dioveo's answer is unusually short because the product genuinely does not store the message bodies it processes — and a short, true answer is much easier to evidence than a long, careful one.
Show your privacy policy matches reality. The reviewer reads it against your actual behaviour. Boilerplate that mentions data you do not collect, or omits a transfer you do make, is a finding. This is where the "written by a lawyer who never saw the architecture" policy fails.
Show the in-product disclosure. Users must understand what they are granting at the moment they grant it. The consent screen, the copy around it, and a demo video of the flow are all part of the submission.
Pass the scan. TLS configuration, authentication and session handling, access control, input validation, dependency vulnerabilities, error handling that does not leak internals. Standard ASVS territory — unglamorous, and entirely fixable in advance.
What actually slowed us down
The demo video. Google wants to watch a real user journey through the consent flow to the feature the scope enables. Ours was rejected once for not showing enough of the path before the grant. That single item added a round trip and about ten days.
Dependency findings in code we did not write. Transitive dependencies with known CVEs, most of them unreachable from our code paths. It does not matter — you upgrade or you document why it is not exploitable, and documenting is slower than upgrading.
Turnaround, not work. The engineering was perhaps two weeks. The calendar was closer to two months, because each round trip with the lab has its own queue. This is the number to plan around, and the one every team underestimates.
What we would tell a team starting now
Decide your scopes before you design the product. Scope choice is a product constraint, not an integration detail. Building a feature that needs a scope you cannot justify means removing the feature later.
Write the privacy policy from the architecture. Not from a template. If the two disagree, you either change the policy or change the system, and finding out which during review is expensive.
Collect evidence continuously. Dependency scans, access reviews, and change records requested as a batch are painful; the same artifacts produced by your pipeline every day are free. This is the same principle behind SOC 2 and ISO 27001 readiness, and the work overlaps heavily — if you are doing one, scope for the others.
Budget the calendar, not the effort. Assume two months of elapsed time with an engineer available to turn findings around quickly. Launching into a deadline without that slack is how teams end up shipping with degraded scopes.
Why we write this down
We do this work for clients — SOC 2 readiness, ISO 27001 and 27002 control implementation, CASA and OAuth verification, and the evidence automation underneath all three. We are not an audit firm, and certification is issued by an accredited auditor rather than by us. What we do is build the controls so that the audit is a formality rather than a fire drill.
We put the detail in public because a claim you cannot check is worth nothing, and "we have security expertise" is exactly that kind of claim. This is the checkable version.
If you have a restricted-scope review coming, or a customer security questionnaire you cannot answer yet, tell us where you are.