--- title: "Requirements and Assessments FAQs for Google Health API" canonical: "https://help.validic.com/space/VCS/5539037190/Requirements%20and%20Assessments%20FAQs%20for%20Google%20Health%20API" format: markdown --- # Requirements and Assessments FAQs **Contents:** > Macro (toc) Last Updated: July 24, 2026 --- If you're integrating with the Google Health API, you've probably run into some questions about CASA security assessments and what the approval process actually looks like. Here's a straightforward breakdown of the most common questions we hear. --- ## What requirements and assessments do I need to prepare for? All of the health data scopes for Google Health API are considered restricted scopes by Google. So you're looking at two distinct gatekeeping processes that run in sequence. Knowing what each one involves, and what you need to have ready, goes a long way toward avoiding delays. ### **The two processes you need to clear:** 1. **OAuth App Verification** This is Google's review of your app before it's allowed to access sensitive or restricted user data at scale. Think of it as Google's way of confirming your app is real, legitimate, and handles user data responsibly. **To get through OAuth verification, you'll need:** - A production-ready OAuth consent screen with your app name and logo matching your actual product and website - A live, public website with real content about your app (not a placeholder or coming-soon page) - A publicly accessible Privacy Policy that explicitly mentions Google data and health data: what you collect, why, how you store it, and who you share it with - Terms of Service that are publicly accessible - A short screen recording walking through your complete OAuth grant flow, showing the user experience from login through where the data lands in your app. Google specifically asks for this for restricted scopes. - Justification for each restricted scope you're requesting: why your app needs it and how it's used The general rule here is: request only the scopes you actually need. Every restricted scope you add increases scrutiny and can extend review time. A note on branding before you submit - Before your consent screen shows your app name and logo, you need to complete brand verification ([console.cloud.google.com/auth/branding](http://console.cloud.google.com/auth/branding)), a separate and earlier Google process that confirms domain ownership. Until brand verification completes, your consent screen will continue to show "[syncmydevice.com](http://syncmydevice.com) wants access to your Google Account," Validic's marketplace redirect domain, rather than your app name and logo. This is expected, not an error. 2. **CASA Security Assessment** For apps using restricted scopes (which includes Google Health API data), an annual CASA security assessment through an authorized third-party lab is required. This is not optional, and self-scan-only assessments are no longer accepted. In addition, the former Tier 2 and Tier 3 assessments have been replaced by AL1 and AL2 [assurance levels](https://appdefensealliance.dev/casa/casa-tiering). The assessment evaluates your app against OWASP ASVS security controls and covers things like authentication, data protection, infrastructure security, and secure development practices. The depth of the assessment depends on your assigned tier (AL1 or AL2), which Google determines based on your data sensitivity, user scale, and risk profile. ### **Here's what labs typically need from you to run the CASA assessment:** **Security architecture documentation** - Architecture diagrams showing how your system is structured - Data flow diagrams showing how data moves between users, Google Health, your backend, databases, and any third-party services **Data handling policy** - What Google/health data you collect and why - Where data is stored and for how long - Who has access and under what conditions - How data is deleted when no longer needed **Access controls** - An access control matrix showing which team members can access production data and what their permissions are - Evidence of least-privilege access policies in your cloud environment **Security scan results** - Results from DAST and/or SAST scans you've run internally - Documentation of what you scanned, when, and how you addressed findings **Incident response process** - How your team handles security reports, vulnerability disclosures, and outages - Patching and update procedures **Technical security implementation evidence** - Confirmation that OAuth is implemented securely (no client secrets in front-end code, proper token storage and rotation) - Confirmation that health data is encrypted in transit (HTTPS everywhere) and at rest - Evidence of session security: secure cookies, timeouts, CSRF protection ### **Quick reference: what you're preparing for** | | | | | --- | --- | --- | | **Stage** | **What It Is** | **What You Need to Prepare** | | 1. **OAuth App Verification** | Google reviews your app, scopes, branding, and policies before granting access to sensitive or restricted data. | App branding, Privacy Policy, Terms of Service, OAuth consent screen, demo video of login flow | | 2. **CASA Security Assessment** | A third-party lab audit of your app's security posture, required for restricted scope access. Tier (AL1 or AL2) assigned by Google. | Architecture diagrams, data flow diagrams, data handling policy, access controls, security scan results, incident response plan | ### **A note on sequencing** These two processes are related but separate. OAuth verification is your first step, and that's where Google will tell you whether a CASA assessment is required and at what tier. That said, the documentation and security baseline work for CASA overlaps significantly with what makes a strong OAuth submission, so building them together is the most efficient approach. Keep in mind that the CASA assessment is a yearly assessment so you will also need to prepare to renew it annually. [[Back to Top]](#top) --- ## How do I get started with OAuth verification and CASA? These are two separate steps that happen in order. You start OAuth verification yourself. CASA is usually triggered for you by Google during that review. Here is the path from start to finish. ### Step 1: Prepare before you submit Have these ready first, because Google checks all of them during OAuth review: - A live public website and a production-ready OAuth consent screen with your real app name and logo (requires brand verification to be completed first, see note above) - A public Privacy Policy that specifically names Google data and health data, plus public Terms of Service - A short screen recording of your full OAuth login flow, showing where the data lands in your app - A written justification for each restricted scope you request (only request what you actually use and can demonstrate use of) ### Step 2: Submit for OAuth verification In the Google Cloud Console, open your project and go to the Google Auth Platform (formerly APIs and Services > OAuth consent screen). Select the sensitive and restricted scopes your app needs, then click **Submit for verification**. Google's team reviews your app, branding, policies, and scopes. See [Restricted scope verification](https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification) and the [OAuth App Verification Help Center](https://support.google.com/cloud/answer/13463073). ### Step 3: Google tells you if CASA is required, and at what level If your app stores or transmits health data on a server, Google will require a CASA security assessment. You will receive an email that opens a case and states your required assurance level, either **AL1** (developer tested, lab reviewed) or **AL2** (lab tested by the assessor). Most health apps are assigned AL1. You do not pick your level; Google assigns it based on data sensitivity, user count, and risk. See [Security Assessment overview](https://support.google.com/cloud/answer/13465431) and [CASA Assurance Levels](https://appdefensealliance.dev/casa/casa-tiering). ### Step 4: Complete your CASA assessment Once your case is open, the CASA Portal shows a Getting Started page that identifies which requirements apply to your app. From there: 1. Run the required security scans on your app. 2. Choose an [authorized CASA assessor](https://appdefensealliance.dev/casa/casa-assessors) and agree pricing and timing directly with them. Google is not involved in that arrangement. 3. Submit your scan results and supporting evidence to the assessor through the portal. 4. The assessor confirms your evidence is complete and issues a **Letter of Validation**. For AL1, the assessor reviews your evidence without needing access to your code or infrastructure. This typically takes a few weeks. See the [CASA Tier 2 / AL1 process](https://appdefensealliance.dev/casa/tier-2/tier2-overview). ### Step 5: Verification completes and your user cap lifts After Google receives your Letter of Validation and finishes OAuth verification, the 100-new-user cap on your app is removed and you can onboard at full scale. Remember that CASA is an annual assessment, so plan to renew it every 12 months from your Letter of Validation date. ### A note on the 100-user limit and Validic's exception Until you finish your own verification, Google limits your app to 100 new users. That is Google's standard rule for unverified apps using health data scopes. Validic has a separate exception from Google that lets Validic keep onboarding partners while Validic completes its own assessment. That keeps the pipeline moving, but it does not remove your own requirement to verify your app or lift the 100-user cap on your app. Ask your Validic contact for the latest status and dates on Validic's OAuth verification and CASA assessment. [[Back to Top]](#top) --- ## Where can I find more information from Google? Google has FAQs and documentation on their website: [https://support.google.com/cloud/answer/13463073?hl=en&ref_topic=13460882&sjid=2467733560324976791-NA](https://support.google.com/cloud/answer/13463073?hl=en&ref_topic=13460882&sjid=2467733560324976791-NA) Additional Helpful Information: - [Restricted scope verification (developer guide)](https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification) - [OAuth App Verification Help Center](https://support.google.com/cloud/answer/13463073) - [OAuth Verification Requirements](https://support.google.com/cloud/answer/13464321) - [Security Assessment overview](https://support.google.com/cloud/answer/13465431) - [CASA Assurance Levels (AL1 / AL2)](https://appdefensealliance.dev/casa/casa-tiering) - [CASA Tier 2 / AL1 process](https://appdefensealliance.dev/casa/tier-2/tier2-overview) - [Authorized CASA assessors](https://appdefensealliance.dev/casa/casa-assessors) - [Manage App Audience (user cap)](https://support.google.com/cloud/answer/15549945) [[Back to Top]](#top) --- ## For CASA, what's the difference between AL1 and AL2, just so I know what I might be dealing with? Think of it as the difference between a focused audit and a full deep-dive: ### **AL1 (Developer Tested, Lab Reviewed)** - Covers many critical security controls (based on OWASP ASVS standards) - Typically for apps with sensitive or restricted scopes at moderate risk levels - Usually involves lab-guided scanning with lab validation - Less time-intensive and generally lower cost than AL2 ### **AL2 (Lab Tested)** - Comprehensive manual testing of the app, its infrastructure, and data storage - Reserved for higher-risk profiles or apps requiring independent security verification badges - Significantly more lab hours and higher cost Most health data apps end up at AL1, but you won't know for sure until Google tells you. [[Back to Top]](#top) --- ## How do I find out if I need CASA AL1 or AL2? Short answer: Google tells you. You don't get to pick, and there isn't a public checklist that maps specific scopes to a specific tier. Google assigns your required tier based on a few factors: - How sensitive the data is (health and fitness data is treated as high sensitivity) - How many users your app has or is expected to have - Your app's overall risk profile The way you find out your assigned tier is through the OAuth verification process. Once you submit your app and request health-related scopes, Google's team reviews everything and responds with whether a CASA assessment is required and, if so, which tier. You'll see this in an email from the Google Cloud or OAuth team, and it will be explicit: something like "you must complete a CASA AL1 assessment." *You can also check the Google Cloud Console under APIs & Services > OAuth consent screen for any linked security assessment notices, but the clearest signal will come directly from Google's team during the review process.* [[Back to Top]](#top) --- ## Can I get started before Google assigns my tier? Yes, absolutely, and we'd recommend it. There's a lot of prep work you can do now that will save you time and headaches once the assessment officially kicks off. Here's what you can work on right now: ### **Get your OAuth house in order** - Request only the scopes you genuinely need. Broader or more sensitive scopes are what trigger stricter review, so don't ask for more than your app actually uses. - Make sure your app name, branding, website, Privacy Policy, and Terms of Service are all polished and consistent. Google checks all of this, and your privacy policy needs to specifically call out Google data and health data. - Prepare a short screen recording that walks through your full OAuth login flow and shows where data goes in your app. Google asks for this during restricted scope verification. ### **Build your security baseline** Both Google and the CASA labs align their requirements to OWASP ASVS controls, so you can start working toward compliance now: - Make sure OAuth is implemented securely (no client secrets in your front end, proper token storage and rotation) - Confirm all health data is encrypted in transit and at rest - Lock down your cloud environment with least-privilege access controls and proper secrets management - Run internal security scans (DAST/SAST) and document what you ran and when ### **Prepare your documentation** Labs will ask for this during the assessment, so having it ready early saves real time: - Architecture and data flow diagrams showing how data moves between the user, Google Health, your backend, and any third-party services - A written data handling policy: what you collect, why, where it's stored, how long you keep it, and who has access - A basic incident response plan: how you handle security reports, patching, and outages - An access control matrix showing who on your team can access production data and under what conditions [[Back to Top]](#top) --- ## Can I choose my own assessor? Yes, choosing your lab is actually one of the few decisions that's fully yours to make. Once Google tells you which tier is required, you're free to pick [any authorized CASA lab](https://appdefensealliance.dev/casa/casa-assessors) and negotiate pricing and timing directly with them. You can even start scoping this out before Google assigns your tier. A few things worth doing now: - Identify two or three authorized CASA labs that work with health data apps - Reach out informally to ask about typical timelines from start to Letter of Validation, how they work with early-stage companies, and what documentation they'll need from you - Get a rough sense of pricing so there are no surprises You may not sign a contract until you know your tier, but doing the legwork now means you won't be scrambling once Google's email arrives. [[Back to Top]](#top) --- For apps using restricted scopes (which the Google Health APIs fall under), self-scan-only assessments are no longer accepted. An external lab is required. So factoring lab selection into your timeline is important. If you have questions about where your app falls in this process or want help thinking through your prep checklist, reach out to your Validic contact and we're happy to work through it with you.