CASA Assessment Tool & Platform

The trigger is the type of OAuth permission your application asks Google users for, not the size of your organisation. An application requesting sensitive scopes goes through OAuth verification; one requesting restricted scopes, those covering the most protected content such as mail or files, must also demonstrate its application security level through CASA. An application used only by accounts inside your own organisation sits outside that verification. Scope is therefore settled application by application.

CASA is tiered. At the lighter end sits a self-assessment backed by evidence and by automated scanning of the application; at the most demanding end, an assessment run by an authorised laboratory that adds its own testing and a documentation review. The tier is not a comfort setting a vendor picks: it follows from the verification Google asks for and from the risk carried by the data the application reaches. The preparation work is the same either way; only the standard of proof changes.

Not in the sense of ISO 27001: there is no accredited scheme and no certificate covering the organisation as a whole. CASA is the App Defense Alliance framework Google uses in its OAuth verification; an assessment run by an authorised laboratory ends in a letter of validation, tied to one application and to the permissions it requests, which you pass on to Google. It is not settled once and for all: while the application keeps restricted scopes the assessment has to be redone each year, and changing the scopes you request restarts the verification.

The ASVS is the application security verification standard published by OWASP, and CASA builds its requirements on it. It covers authentication and session management, access control, input validation, cryptography and secrets handling, logging, dependency management and the security of the development lifecycle. The logic throughout is evidential: for each requirement, show not an intention but a control that is in place and can be checked.

No. An ISO/IEC 27001 certificate covers an information security management system at organisation level; CASA looks at one application and its code. Neither replaces the other. That said, much of the evidence already produced for your ISMS, a SOC 2 report or a recent penetration test feeds straight into the CASA file. The common mistake is starting from scratch when the material already exists, scattered across several teams.

The gaps found have to be fixed and submitted again: an assessment is not a one-shot exam. The real risk is not a single failure, it is the calendar. Until the file is validated, Google can restrict the application's access to the scopes concerned, which breaks functionality for your users. That is the argument for handling remediation continuously rather than discovering the gaps a few weeks before the deadline.

Because a CASA file is not a list of ticked boxes but a set of links: which requirement, which control covers it, which evidence supports it, who owns it and when it was last reviewed. A spreadsheet loses those links from one cycle to the next, so the work is redone identically the following year. A platform keeps them, flags evidence that has gone stale between assessments and reuses what is still valid, including for your other frameworks.