Security assessment requirements for an Apps Script Sheets Editor add-on using the restricted Drive scope

Google Cloud Cloud Foundations & Onboarding
1

Hello,

I am developing an unpublished Google Sheets Editor add-on in Google Apps Script for community and neighborhood association accounting. I am considering a future public, paid release and would appreciate guidance before proceeding with OAuth verification or a paid security assessment.

Current architecture:

  • Accounting records and reports are stored in each user’s own Google Sheets spreadsheet.

  • Backups are copies of the accounting spreadsheet stored in that user’s own Google Drive. The add-on also reads backups to verify their contents.

  • Accounting operations run on Google’s Apps Script servers under the initiating user’s authorization. The current implementation does not use a developer-hosted server, external accounting database, or third-party analytics SDK.

  • An optional HTML interface exchanges financial totals and operation results through google.script.run. Document Properties stores only a setup marker and spreadsheet ID, not transaction details.

  • Apps Script exception logging is enabled, and exceptions are logged through console.error/warn. Exceptions may contain file-related information; actual log contents, retention, and administrator access still need review before release. I am not claiming that data never leaves Google Sheets or that operators can never access logs.

The currently requested OAuth scopes are:

  • drive (full Google Drive access; restricted scope)

  • spreadsheets

  • script.container.ui

  • userinfo.email

These are the standard Google OAuth scope names, listed without URL prefixes.

My questions are:

  1. Could this architecture require an annual third-party security assessment because it uses the restricted Drive scope?

  2. How are Google’s Apps Script runtime and Google-managed exception/Cloud Logging treated under the requirements for accessing, storing, or transmitting restricted data through servers?

  3. Are there conditions under which this architecture would not require that assessment? Alternatively, could a narrower scope such as drive.file change the requirements while preserving backup creation, verification, and access to existing backups?

  4. What procedure should I follow to obtain a project-specific determination from Google’s authorized review team?

  5. Is there an official pre-submission contact route for these questions before submitting for OAuth verification?

I understand that community advice is not a formal exemption, approval, or permission to publish. I am seeking policy references and the correct review route, not a way to bypass verification.

Thank you for your guidance.