Require 2-Step Verification for users 2-Step Verification helps protect a user account from unauthorized access should someone manage to obtain their password. Protect your business with 2-Step Verification | Deploy 2-Step Verification | |
Enforce security keys, at least for admins and other high-value accounts Security keys are small hardware devices used when signing in that provide second factor authentication that resists phishing. |
Help prevent password reuse with Password Alert Use Password Alert to make sure users don't use their corporate passwords on other sites. | |
Use unique passwords A good password is the first line of defense to protect user and admin accounts. Unique passwords aren’t easily guessed. Also discourage password reuse across different accounts, such as email and online banking. |
Regularly review activity reports and alerts Review activity reports for account status, admin status, and 2-Step Verification enrollment details. | |
Set up admin email alerts Set up email alerts for potentially risky events, such as suspicious sign-in attempts, compromised mobile devices, or setting changes by another admin. | |
Add user login challenges Set up login challenges for suspicious login attempts. Users must enter a verification code that Google sends to their recovery phone number or recovery email address, or they must answer a challenge that only the account owner can solve. Verify a user’s identity with extra security | Add employee ID as a login challenge | |
Identify and secure compromised accounts If you suspect an account may be compromised, suspend the account, investigate for malicious activity, and take action if necessary.
| |
Turn off Google data download as needed If an account is compromised or the user leaves the company, prevent that user from downloading all their Google data with Google Takeout. | |
Prevent unauthorized access after an employee leaves To prevent data leaks, revoke a user’s access to your organization’s data when they leave. |
Review third-party app access to core services Know and approve which third-party apps can access Google Workspace core services such as Gmail and Drive. Control which third-party & internal apps access Google Workspace data | |
Block access to less secure apps Less secure apps don’t use modern security standards, such as OAuth, and increase the risk of accounts or devices being compromised. | |
Create a list of trusted apps Create an allowlist that specifies which third-party apps can access core Google Workspace services. Control which third-party & internal apps access Google Workspace data | |
Control access to Google core services You can allow or block access to Google apps such as Gmail, Drive, and Calendar based on a device’s IP address, geographic origin, security policies, or OS. For example, you can allow Drive for desktop only on company-owned devices in specific countries/regions. | |
Add another layer of encryption to users' apps data If your organization works with sensitive intellectual property or operates in a highly regulated industry, you can add client-side encryption to Gmail, Google Drive, Google Meet, and Google Calendar. |
Limit external calendar sharing Restrict external calendar sharing to free/busy information only. This reduces the risk of data leaks. | |
Warn users when they invite external guests By default, Calendar warns users when they invite external guests. This reduces the risk of data leaks. Make sure this warning is on for all users. |
Limit who can chat externally Allow only the users with a specific need to send messages or create rooms with users outside your organization. This prevents external users from seeing previous internal discussions and reduces the risk of data leaks. | |
Warn users when chatting outside their domain (classic Hangouts only) Show users a warning when they chat with people outside their domain. When enabled, group chat conversations are split when the first person from outside the domain is added to the discussion. This prevents external users from seeing previous internal discussions and reduces the risk of data leaks. In Chat, external users and rooms are always marked "External." | |
Set a chat invitation policy Determine which users can automatically accept chat invitations based on your organization’s policy on collaboration. |
Keep Chrome browser and Chrome OS updated To ensure your users have the latest security patches, allow updates. For Chrome browser, always allow updates. By default, Chrome OS devices update to the latest version of Chrome when it’s available. Make sure auto-updates are turned on for all your Chrome OS device users. | |
Force a relaunch to apply updates Set Chrome browser and Chrome OS devices to notify users that they need to relaunch their browsers or restart their devices for the update to apply, and force a relaunch after a set time if the user doesn’t take action. | |
Set basic Chrome OS device and Chrome browser policies Set the following policies in your Google Admin console:
| |
Set advanced Chrome browser policies Prevent unauthorized access, dangerous downloads, and data leaks between sites by setting the following advanced policies:
Set Chrome Browser policies on managed PCs | Chrome Browser Enterprise Security Configuration Guide (Windows) | |
Set a Windows desktop browser policy If your organization wants to use Chrome Browser but your users still need to access older websites and apps that require Internet Explorer, the Chrome Legacy Browser Support extension lets users switch automatically between Chrome and another browser. Use Legacy Browser Support to support applications that require a legacy browser. |
Turn off automatic creation of Currents profiles Disable automatic creation of public Currents profiles for users in your organization. | |
Limit how users share and view external Currents content For example, you might want to prevent users from creating or interacting with external content. |
Set options or create rules for file sharing outside your organization Confine file sharing within the boundary of your domains by turning off sharing options or by creating trust rules (which give you more precise control over sharing). This reduces data leak and data exfiltration risks. If sharing is required outside of your organization because of business needs, you can define how sharing is done for organizational units, or you can designate domains on your allowlist. Restrict sharing outside allowed domains | Restrict sharing outside your organization | Create trust rules to restrict external sharing | |
Warn users when they share a file outside your domain If you allow users to share files outside your domain, turn on a warning when a user does so. This allows users to confirm whether this action is the intended one, and reduces the risk of data leaks. | |
Prevent users from publishing on the web Disable file publishing on the web. This reduces the risk of data leaks. | |
Set general access options for file sharing Set the default access option for file sharing to Restricted. Only the file owner should have access until they share the file. Optionally, create custom sharing groups (target audiences) for users in different departments. | |
Limit file access to recipients only When a user shares a file via a Google product other than Docs or Drive (for example, by pasting a link in Gmail), Access Checker can check that the recipients can access the file. Set up Access Checker for Recipients only. This gives you control over the accessibility of links shared by your users, and reduces the risk of data leaks. | |
Prevent or limit the risk that external users can discover your organization’s group memberships To prevent users at another organization that uses Google Workspace from discovering your organization's group memberships, don't allow external organizations to share files with your users. Or, to limit this type of risk, allow external sharing only with allowlisted domains. If you use Google Drive sharing settings: For each organizational unit you want to protect from this risk, do one of the following:
For details, see Manage external sharing for your organization. If you use trust rules for Drive sharing: To limit this risk, first create a trust rule with the following settings:
For details, see Create a trust rule. Next, deactivate the default rule named [Default] Users in my organization can share with a warning and receive from anyone. For details, see View or edit trust rule details. | |
Require Google sign-in for external collaborators Require external collaborators to sign in with a Google Account. If they don't have a Google Account, they can create one at no cost. This reduces the risk of data leaks. Turn off invitations to non-Google accounts outside your domain | |
Limit who can move content from shared drives Allow only users in your organization to move files from their shared drives to a Drive location in a different organization. | |
Control content sharing in new shared drives Restrict who can create shared drives, access content, or change the settings for new shared drives. |
Disable access to offline docs To reduce the risk of data leaks, consider disabling access to offline docs. When docs are accessible offline, a copy of the document is stored locally. If you have a business reason to enable access to offline docs, enable this feature per organizational unit to minimize risk. | |
Disable desktop access to Drive Users can get desktop access to Drive with Google Drive for desktop. To reduce the risk of data leaks, consider disabling desktop access to Drive. If you decide to enable desktop access, enable it only for users with a critical business need. |
Don't allow Google Docs add-ons To reduce the risk of data leaks, consider not allowing users to install add-ons for Google Docs from the add-on store. To support a specific business need, you can deploy specific add-ons for Google Docs that are aligned with your organizational policy. |
Block or warn on sharing files with sensitive data To reduce the risk of data leaks, set up Data Loss Protection rules to scan files for sensitive data and take action when users try to share matching files externally. For example, you can block external sharing of documents that contain passport numbers and get an email alert. |
Authenticate email with SPF, DKIM, and DMARC SPF, DKIM, and DMARC establish an email validation system that uses DNS settings to authenticate, digitally sign, and help prevent spoofing of your domain. Attackers sometimes forge the "From" address on email messages so they seem to come from a user in your domain. To prevent this, you can set up SPF and DKIM on all outbound email streams. Once SPF and DKIM are in place, you can set up a DMARC record to define how Google and other receivers should treat unauthenticated emails purporting to come from your domain. | |
Set up inbound email gateways to work with SPF SPF helps prevent your outgoing messages from being sent to spam, but a gateway can impact how SPF works. If you use an email gateway to route incoming email, make sure it’s set up properly for Sender Policy Framework (SPF). | |
Enforce TLS with your partner domains Set the TLS setting to require a secure connection for email to (or from) partner domains. Require mail to be transmitted via a secure (TLS) connection | |
Require sender authentication for all approved senders When you create an address list of approved senders who can bypass spam classification, require authentication. When sender authentication is turned off, Gmail can't verify the message was sent by the person it seems to come from. Requiring authentication reduces the risk of spoofing and phishing/whaling. Learn more about sender authentication. | |
Configure MX records for correct mail flow Configure the MX records to point to Google’s mail servers as the highest priority record to ensure correct mail flow to your Google Workspace domain users. This reduces the risk of data deletion (through lost email) and malware threats. Set up MX records for Google Workspace Gmail | Google Workspace MX records values |
Disable IMAP/POP access IMAP and POP desktop clients let users access Gmail through third-party email clients. Disable POP and IMAP access for any users who don't explicitly need this access. This reduces data leak, data deletion, and data exfiltration risks. It also can reduce the threat of attacks because IMAP clients might not have similar protections to first-party clients. | |
Disable automatic forwarding Prevent users from automatically forwarding incoming mail to another address. This reduces the risk of data exfiltration through email forwarding, which is a common technique employed by attackers. | |
Enable comprehensive mail storage Comprehensive mail storage ensures that a copy of all sent and received mail in your domain—including mail sent or received by non-Gmail mailboxes—is stored in the associated users' Gmail mailboxes. Enable this setting to reduce the risk of data deletion and, if you use Google Vault, ensure mail is retained or held Set up comprehensive mail storage | Comprehensive mail storage and Vault | |
Don't bypass spam filters for internal senders Turn off Bypass spam filters for internal senders, because any external addresses added to groups are treated as internal addresses. By turning off this setting, you can make sure all user email is filtered for spam, including mail from internal senders. This reduces the risk of spoofing and phishing/whaling. | |
Add spam headers setting to all default routing rules Spam headers help maximize the filtering capacity of downstream email servers and reduce the risks of spoofing and phishing/whaling. When you set up default routing rules, check the Add X-Gm-Spam and X-Gm-Phishy headers box so that Gmail adds these headers to indicate the spam and phishing status of the message. For example, an administrator at a downstream server can use this information to set up rules that handle spam and phishing differently from clean mail. | |
Enable enhanced pre-delivery message scanning When Gmail identifies that an email message may be phishing, this setting enables Gmail to perform additional checks on the message. | |
Enable external recipient warnings Gmail detects if an external recipient in an email response is not someone a user interacts with regularly, or isn't present in a user’s Contacts. When you configure this setting, your users receive a warning and an option to dismiss. | |
Enable additional attachment protection Google scans incoming messages to protect against malware, even if the additional malicious attachment protections settings aren't enabled. Turning on additional attachment protection can catch email that previously wasn't identified as malicious. | |
Enable additional link and external content protection | |
Enable additional spoofing protection Google scans incoming messages to protect against spoofing even if additional spoofing protections settings aren't enabled. Turning on additional spoofing and authentication protection can, for example, reduce the risk of spoofing based on similar domain names or employee names. |
Take care when overriding spam filters To avoid an increase in spam, exercise thought and care if you override Gmail’s default spam filters.
| |
Don't include domains in the approved senders list If you set up approved senders, and if you checked Bypass spam filters for messages received from addresses or domains within these approved senders lists, remove any domains from your approved sender list. Excluding domains from the approved senders list reduces the risk of spoofing and phishing/whaling. | |
Don't add IP addresses to your allowlist In general, mail sent from IP addresses on your allowlist isn't marked as spam. To take full advantage of the Gmail spam filtering service and for best spam classification results, IP addresses of your mail servers and partner mail servers that are forwarding email to Gmail should be added to an Inbound mail gateway, and not an IP allowlist. Add IP addresses to allow lists in Gmail | Set up an inbound mail gateway |
Scan and block emails with sensitive data To reduce the risk of data leaks, scan outgoing emails with predefined Data Loss Protection detectors to take action when users receive or send messages with sensitive content. For example, you can block users from sending messages that contain credit card numbers and get an email alert. |
Use groups designed for security Ensure only select users can access sensitive apps and resources by managing them with security groups. This reduces the risk of data leaks. | |
Add security conditions to admin roles Allow only certain admins to control security groups. Designate other admins that can only control nonsecurity groups. This reduces the risk of data leaks and malicious insider threats. | |
Set up private access to your groups Select the Private setting to limit access to members of your domain. (Group members can still receive email from outside the domain.) This reduces the risk of data leaks. | |
Limit group creation to admins Allow only admins to create groups. This reduces the risk of data leaks. | |
Customize your group access settings Recommendations:
| |
Disable some access settings for internal groups The following settings allow anyone on the internet to join the group, send messages, and view the discussion archives. Disable these settings for internal groups:
| |
Enable spam moderation for your groups You can have messages sent to the moderation queue with or without notifying moderators, immediately reject spam messages, or allow the messages to be posted without moderation. |
Block sharing sites outside the domain Set Google Sites sharing options | Set sharing options: classic Sites |
Treat accounts with Vault privileges as sensitive Protect accounts assigned to Vault administrator roles the same way you protect super admin accounts. | |
Regularly audit Vault activity Users with Vault privileges can search and export other users’ data, as well as change retention rules that can purge data you need to keep. Monitor Vault activity to ensure that only approved data access and retention policies occur. |
Review your security settings and investigate activity Regularly visit the security center to review your security posture, investigate incidents, and take action based on that information. | |
Review the Admin audit log Use the Admin audit log to review a history of every task performed in the Google Admin console, which admin performed the task, the date, and the IP address from which the admin signed in. |