Security and privacy for administrators

Two of the most common topics of questions regarding Google in general, and Google Apps specifically, are security and privacy. We take both topics very seriously and truly believe that our offerings are a great option for customers on both fronts. Our business is built on our users' trust: trust in our ability to properly secure their data and our commitment to respect the privacy of the information they place in our systems by not giving that information to others or using it inappropriately.

To learn more about Google's position on reliability, privacy, and security, see How Google Handles your data.

To help answer some of the questions you may have as a Google Apps administrator, we've created this FAQ.


Which of my users can gain access to my Google Apps administrative account?

Only the owner and managers of the domain name can create a Google Apps administrative account. Upon signing up, a Google Apps administrator is asked to verify control of the domain by making a change to the DNS records. Without this verification, Google will not allow an administrative account to be opened. None of the Google services can be actively managed for a domain until domain ownership is verified.

After an administrator has verified ownership, other usernames in the account may be granted administrative privileges at the discretion of any administrator.

Non-administrative users on the domain may also contact the Google Apps Support team to request administrative access. The normal domain verification process will take place to ensure that the requestor has domain management rights.

Lastly, any individual who has access to your registered secondary email address can initiate a password reset and access the primary administrator account.

Which of my end-users can gain access to other end-users' accounts?

Per your domain’s Customer Agreement, Google Apps administrators for a domain can access all end-user accounts and the associated data, as described in our Privacy Policy.

As a domain administrator, you have control of all usernames and passwords within your domain. You may access your users' accounts in conformity with the Customer Agreement. We do require that you have a policy about such actions that is published to your end-users.


What does a Google Apps SOC 2/3 audit mean to me?

An independent third party auditor issued Google Apps an unqualified SOC 2/3 audit opinion. Google is proud to provide Google Apps administrators the peace of mind knowing that their data is secure under the SOC 2/3 auditing industry standards.

The independent third party auditor verified that Google Apps has the following controls and protocols in place:

  • Logical security: Controls provide reasonable assurance that logical access to Google Apps production systems and data is restricted to authorized individuals
  • Privacy: Controls provide reasonable assurance that Google has implemented policies and procedures addressing the privacy of customer data related to Google Apps
  • Data center physical security: Controls provide reasonable assurance that data centers that house Google Apps data and corporate offices are protected
  • Incident management and availability: Controls provide reasonable assurance that Google Apps systems are redundant and incidents are properly reported, responded to, and recorded
  • Change management: Controls provide reasonable assurance that development of and changes to Google Apps undergo testing and independent code review prior to release into production
  • Organization and administration: Controls provide reasonable assurance that management provides the infrastructure and mechanisms to track and communicate initiatives within the company that impact Google Apps
Can my organization use our own authentication system to provide user access to Google Apps?
We make it easy to use Google account security by giving employees secure single sign on access to a wide set of SaaS and custom-built apps on desktop and mobile devices. Our OpenID Connect (OIDC) Identity Provider support can be used with many SaaS apps in the Google Apps Marketplace, and has support for SAML 2.0 (Security Assertion Markup Language) for more than 15 popular SaaS providers. We’re also making it easy for admins to add new custom SAML app integrations. Organizations can do the integration themselves, or work with a Google partner to accomplish this.
How are Google passwords generated for Google Apps user accounts?

To generate passwords for new user accounts, Google uses a mixed pattern of symbols, upper and lower case letters, and numbers. The length of the password will be the greater of the required minimum (8), or the minimum password length you've set for your domain.

An administrator/end-user deleted a number of email messages, how can I recover them?

Once an administrator or end-user has deleted any data in Google Apps, we delete it according to your Customer Agreement and our Privacy Policy.

Data is irretrievable once an administrator deletes a user account. See the Help Center for best practices for deleting users.

If you need to recover email messages, Google offers additional archiving products that can complement Google Apps for Work, Government and Education editions. For non-email data recovery solutions, please consult the Google Apps Marketplace where one of our partners may have a solution suitable for your needs.

Is my organization's data safe from your other customers when it is running on the same servers?

Yes. Data is virtually protected as if it were on its own server. Unauthorized parties cannot access your data. Your competitors cannot access your data, and vice versa. In fact, all user accounts are protected via this virtual lock and key that ensures that one user cannot see another user's data. This is similar to how customer data is segmented in other shared infrastructures such as online banking applications.

Google Apps has received a satisfactory SOC 2/3 audit. This means that an independent auditor has examined the controls protecting the data in Google Apps (including logical security, privacy, Data Center security, etc) and provided reasonable assurance that these controls are in place and operating effectively.


I'm being asked to sign in at a different page. Why?

To help protect you against identity theft, we don't allow unauthorized non-Google web pages to collect your Google username and password. Otherwise, a malicious website that wanted to steal your password could more easily pose as a friendly site. This form of fraud is called phishing.

If you're ever in doubt, take a look at the internet address that's displayed in your browser's address bar. If the address isn't a Google website, don't enter your Google username and password.

One exception to this policy is the single sign-on feature offered in Google Apps for Work. Administrators can integrate Google services with existing web pages to provide a smooth user experience. Learn more


Spammers can sometimes forge the “From” address on an email message so that it appears to come from a reputable organization’s domain.

Known as phishing, this practice is often an attempt to collect sensitive data. To help prevent phishing, Google participates in the DMARC program, which lets domain owners tell email providers how to handle unauthenticated messages from their domain. Google Apps customers can implement DMARC by creating a DMARC record within their admin settings and implementing an SPF record and DKIM keys on all outbound mail streams.

How does Google respond to users in my domain who are sending spam?

If Google identifies a Google Apps email user who is spamming, we reserve the right to immediately suspend the user. If the spam is domain-wide, we reserve the right to suspend the entire account and deny administrator access to all the Google Apps services. This is in accordance with the Google Apps Acceptable Use Policy.

We will notify the registered secondary email address of any spam violations.

Need to report abuse? Please see our Reporting Abuse Incidents page.
Can my organization use our own authentication system to provide user access to Google Apps?

Google Apps integrates with standard web single sign-on systems using the SAML 2.0 standard. Organizations can do the integration themselves, or work with a Google partner to accomplish this.

  Why are application OAuth tokens revoked when an end user's password is changed?

To increase account security for Google Apps users, OAuth2 tokens issued for access to certain products are revoked when a user's password is changed. For example, if a user loses their device and changes their Google password, their mail and other data stops syncing to that device when the password is reset.

Users have always had the ability to revoke access to applications in Security Checkup, and admins have always had this ability in the Google Apps Admin console. This change in our security policy simply automates the token revocation process.

Was this article helpful?