Chat and Meet Security Settings for Google Workspace

Adelia Risk audits chat and meeting settings in every Google Workspace security review we perform. Google Chat is your team’s secure instant messaging platform for business communication, and Google Meet handles video calls, screen sharing, and real-time collaboration. Google Workspace security gaps in these areas don’t always get the same attention as email or file sharing, but the risks are real. An open chat platform lets third-party apps read your messages. And a meeting without access controls can let anyone with a link walk in.

Attackers are increasingly targeting collaboration tools, not just inboxes. Google Chat security controls and Google Meet safety settings all need to be part of your security plan.

This page covers the nine chat and meeting settings Adelia Risk reviews as part of our Google Workspace security audit services. These sit within our 97-setting benchmark across eight security areas. Each setting below includes what it does, why it matters, and what we recommend, sorted from highest risk to lowest.

Quick Reference

Policy ID	Setting	Risk	Heads Up?	Admin Path
CHAT-050	DLP rules configured for Chat	🟠 High	No	Security > Access and Data Protection > Data protection
CHAT-005	Chat history settings configured	🟡 Medium	Yes	Apps > Google Workspace > Google Chat > History for Chats
CHAT-010	Chat Apps disabled	🟡 Medium	Yes	Apps > Google Workspace > Google Chat > Chat Apps
CHAT-015	External chat restrictions	🟡 Medium	Yes	Apps > Google Workspace > Google Chat > External Chat Settings
CHAT-020	Google Meet safety settings configured	🟡 Medium	No	Apps > Google Workspace > Google Meet > Meet Safety Settings
CHAT-025	Meet external participant controls configured	🟡 Medium	No	Apps > Google Workspace > Google Meet > Meet Safety Settings
CHAT-030	Meet recording controls configured	🟡 Medium	No	Apps > Google Workspace > Google Meet > Meet Video Settings
CHAT-035	Meet PSTN dial-in controls restricted	🟢 Low	No	Apps > Google Workspace > Google Meet > Meet Video Settings
CHAT-045	Calendar offline access disabled	🟢 Low	Yes	Apps > Google Workspace > Calendar > General Settings

Heads Up? Does your team need advance notice before you make this change? “Yes” means users will see something different. We’ve included sample language you can send to your team for every “Yes” setting.

CHAT-050: DLP Rules Configured for Chat (Enterprise SKU only)

What This Does

Data Loss Prevention (DLP) rules for Google Chat scan outgoing messages and attachments for sensitive information, like Social Security numbers, credit card numbers, account numbers, or other patterns you define. When a rule triggers, it can block the message, warn the user, or log the event for admin review.

Why It Matters

Chat feels casual. That’s the problem. People share things in a quick message that they’d never put in a formal email. An employee sends a client’s Social Security number to a coworker to “look something up.” Someone pastes an account number into a group chat. A new hire drops a spreadsheet with personal data into a Space.

Without DLP, none of this gets flagged. We see this pattern in almost every Chat DLP audit we run. Most organizations set up email DLP and assume Chat is covered. It isn’t. With Google Chat DLP, you can set rules that catch these patterns before they reach the wrong person, or at least create an audit trail that shows the data was shared. For regulated industries, the audit trail alone is often a compliance requirement.

Relevant to: HIPAA (PHI in messages), SEC Reg S-P (client financial data), PCI-DSS (card numbers in chat).

What We Recommend

• Start with audit-only mode. This logs DLP events without blocking messages. It lets you see what sensitive data is flowing through Chat before you start blocking anything.
• Define rules for your most sensitive data types: Social Security numbers, credit card numbers, financial account numbers, and any industry-specific identifiers
• After 2-4 weeks of audit data, switch the most critical rules to “warn” or “block” mode
• Review DLP incident reports monthly to catch new patterns

Where to Find It

Admin Console path: Security > Access and Data Protection > Data protection

📄 Google documentation: Prevent data leaks from Chat messages and attachments

What Your Team Will Notice

In audit-only mode, nothing changes for users. Messages go through as normal, and only admins see the logs. When you switch to “warn” mode, users who trigger a rule will see a prompt telling them their message may contain sensitive data, with the option to send anyway or edit it. In “block” mode, the message won’t send and the user will see an explanation.

Most users appreciate the warning. It catches honest mistakes before they become incidents.

Common Mistakes

• Skipping Chat DLP because you already have email DLP. Email DLP and Chat DLP are separate rule sets. Setting up one doesn’t cover the other. People share different things in chat than they do in email.
• Going straight to “block” mode. This causes frustration and false positives. Always start with audit-only, review the results, tune your rules, then escalate enforcement.
• Not including attachment scanning. DLP rules can scan files uploaded through Chat, not just message text. Make sure your rules cover both.
• Forgetting to review the logs. DLP rules in audit mode are useless if nobody reads the reports. Set a monthly review cadence.

Related Settings

• GMAIL-125: DLP Rules Configured for Gmail. The same concept applies to email.
• DRIVE-050: Data Loss Prevention Rules Configured for Drive. DLP for files stored in Drive.
• CHAT-005: Chat History Settings Configured. History must be on for DLP to scan messages effectively.

---

CHAT-005: Google Chat History Settings Configured

What This Does

Google Chat can save or discard message history in direct messages and group chats. This setting controls the default behavior and whether users can override it. When history is ON, messages are saved and searchable. When history is OFF, messages disappear after 24 hours.

Spaces with threaded conversations always keep history on. This setting mainly affects direct messages and group conversations.

Why It Matters

Chat history is a compliance issue for regulated industries. SEC rules require broker-dealers and investment advisors to retain business communications. HIPAA requires audit trails for communications that include patient information. If your team discusses client matters in Google Chat (and they do), you need those messages retained.

Beyond Google Chat compliance requirements, chat history creates an institutional record. When an employee leaves, their chat history captures decisions, approvals, and context that would otherwise walk out the door with them. Turning history off might feel like a privacy win, but it creates a Google Chat retention policy gap that auditors will flag.

We see this configured correctly more often than other Chat settings, which is a nice surprise. Most organizations that use Chat for business have already locked history to ON, with users unable to change it. That’s the right approach for a regulated firm.

What We Recommend

• History for direct messages: ON, history is always on
• History for Spaces: ON (this is the default and usually can’t be changed for threaded Spaces)
• Allow users to change their history setting: OFF for regulated industries. Users shouldn’t be able to turn off retention for business messages.
• Pair this with a Google Vault retention policy for long-term storage

Where to Find It

Admin Console path: Apps > Google Workspace > Google Chat > History for Chats / History for Spaces

📄 Google documentation: Turn chat history on or off for users

What Your Team Will Notice

If history was previously off or user-controlled, turning it on means all messages are now saved. Users will see a “History is on” indicator in their chats. Some employees may feel uncomfortable knowing messages are retained, so a brief explanation helps.

Sample message to your team:

Hi team,

Starting \[date\], Google Chat will save all message history by default, and this setting can’t be turned off individually. This means your direct messages and group chats will be retained.

What you need to know:

1. You’ll see a “History is on” indicator in your chats
2. Messages will be searchable and retained according to our data retention policy
3. This doesn’t change how you use Chat day-to-day

We’re making this change to meet our recordkeeping requirements and protect important business conversations. If you have questions, reach out to \[IT contact/helpdesk\].

Common Mistakes

• Letting users toggle history off. If users can disable history, your retention policy has a gap. Anyone who wants a conversation “off the record” can simply flip the switch.
• Assuming Vault covers everything automatically. Google Vault retention and Chat history are related but separate. Vault can retain data even when history is off, but search and eDiscovery work better when history is on.
• Not communicating the change. Turning on always-on history without telling your team creates trust issues. Be upfront about what’s being retained and why.

Related Settings

• CHAT-050: DLP Rules Configured for Chat. DLP scanning works on Chat messages. History supports better DLP coverage.
• MON-055: Data Retention Configured (Vault). Long-term retention for Chat messages.
• GMAIL-115: Comprehensive Mail Storage Enabled. Same retention concept for email.

---

CHAT-010: Chat Apps Disabled

What This Does

Chat Apps (sometimes called bots) are third-party or custom applications that run inside Google Chat. They can read messages, respond to commands, post content, and connect to outside services. This setting controls whether users can install and use Chat Apps in your organization.

Why It Matters

Every Chat App your team installs gets some level of access to your Chat environment. Some read the message content. Some post messages on behalf of users. Some connect to external services and shuttle data between your Workspace and a third-party server. That’s a data flow that most admins don’t monitor.

The risk is similar to browser extensions or Marketplace apps: each one expands your attack surface. A compromised Chat App could read sensitive conversations, exfiltrate data, or impersonate users. And unlike Marketplace apps, Chat Apps often fly under the radar because they feel like a small add-on, not a full application.

What We Recommend

• If you don’t use Chat Apps: Turn them off. This is the simplest and safest option.
• If you use specific Chat Apps: Disable user installation. Instead, admin-approve only the specific apps your team needs. This mirrors the approach we recommend for APPS-020: Google Marketplace Applications.
• Review any currently installed Chat Apps before disabling. Check what access they’ve been granted.

Where to Find It

Admin Console path: Apps > Google Workspace > Google Chat > Chat Apps

📄 Google documentation: Allow users to install Chat apps

What Your Team Will Notice

If your team uses Chat Apps today (project management bots, notification bots, polling tools), those will stop working. Check with your team before flipping this off. If nobody uses Chat Apps or nobody can name one they depend on, it’s safe to disable.

Sample message to your team:

Hi team,

Starting \[date\], we’re disabling Chat Apps (third-party bots) in Google Chat. This is a security measure to prevent unauthorized apps from accessing our chat conversations.

What this means:

1. Any Chat bots you currently use will stop working
2. You won’t be able to install new Chat Apps
3. Regular Google Chat messaging isn’t affected at all

If you rely on a specific Chat App for your work, let \[IT contact/helpdesk\] know before \[date\] and we’ll review whether to approve it. Otherwise, this change won’t affect your day-to-day.

Common Mistakes

• Leaving Chat Apps enabled “because we might use them someday.” If nobody is using them, turn them off. You can always re-enable them later for specific, approved apps.
• Disabling without checking first. Some teams may have set up workflow automations through Chat Apps without telling IT. A quick survey saves you from breaking something unexpectedly.

Related Settings

• APPS-005: API Application Control Access. Broader third-party app access controls.
• APPS-020: Google Marketplace Applications. Similar concept for Marketplace apps.
• CHAT-050: DLP Rules Configured for Chat. If you do keep Chat Apps on, DLP rules help monitor what’s being shared.

---

CHAT-015: External Chat Restrictions

What This Does

Google Workspace gives admins the ability to control whether users can send and receive Google Chat messages with people outside the organization. When external chat is disabled, your team can only message other users on your domain. When it’s enabled, anyone with a Google account can reach your employees through Chat.

Why It Matters

Chat is informal by design. People fire off messages quickly, without the pause that comes with composing an email. That speed is exactly what makes external chat risky. A team member might share a client list, forward an internal document, or confirm sensitive details without realizing they’re talking to someone outside the company.

Social engineering through messaging platforms is increasing because attackers know this. A message from someone claiming to be a vendor, asking for a quick confirmation or a file, feels routine in Chat. In an email, the same request might trigger more scrutiny. Is Google Chat secure? The platform itself uses encryption in transit, but security depends on how your organization configures external access and user permissions. Google Chat doesn’t carry the same “is this phishing?” reflex that most employees have developed for their inbox.

The question every organization should answer: Does your team actually need to chat with external parties? In many organizations, the honest answer is no. Email, phone calls, and scheduled meetings handle external communication. Chat is primarily an internal collaboration tool. If that describes your organization, disabling external chat removes an entire category of risk with zero impact on daily work.

What We Recommend

Start with these questions before deciding:

1\. Does your team actually use external chat today? Check your Chat logs in the Admin Console. Many organizations have external chat enabled, but rarely use it. If usage is minimal, disabling it is an easy decision.

2\. Can external communication happen through other channels? If your team already uses email, phone, or a dedicated portal for external contacts, Chat may not need to be open to outsiders.

3\. Do you have DLP controls in place? If external chat stays enabled without Data Loss Prevention rules scanning outgoing messages (see CHAT-050), sensitive data can leave your organization through a channel you’re not monitoring.

4\. Are your users trained to recognize social engineering in Chat? Most security awareness training focuses on email phishing. If your team isn’t trained to apply the same skepticism to Chat messages from unknown contacts, external chat creates a blind spot.

Based on your answers:

• If external chat isn’t needed: Disable it entirely. This is the strongest control and the simplest to manage. Your team won’t miss what they weren’t using.
• If external chat is needed with specific external partners: Restrict it to trusted domains only. This lets your team communicate with known external contacts while blocking messages from unknown accounts.
• If external chat must be fully open: Enable DLP rules for Chat (CHAT-050), ensure your security awareness training covers Chat-based social engineering, and review external chat usage logs regularly.

Where to Find It

Admin Console path: Apps > Google Workspace > Google Chat > External Chat Settings

📄 Google documentation: Control external Chat and spaces chat options

Related Settings

• GMAIL-060: External Reply Warning Enabled. Same concept for email replies.
• CHAT-050: DLP Rules Configured for Chat. DLP can scan external chat messages for sensitive data.

---

CHAT-020: Google Meet Safety Settings Configured

What This Does

Google Meet safety features are controlled through a set of admin settings that affect who can do what during a meeting. These include host management controls, screen sharing permissions, and the Meet Media API. The Media API lets third-party integrations capture meeting audio and video. The settings apply organization-wide and determine the default behavior for all meetings.

Why It Matters

Unchecked meeting settings create openings. If the Media API is enabled, third-party apps could access meeting audio and video feeds without explicit per-meeting consent.

“Zoom bombing” (uninvited guests disrupting video meetings) was a headline problem in 2020, but meeting hijacking hasn’t gone away. It’s just gotten less visible. Is Google Meet secure by default? Google Meet security depends on configuration, not just defaults. The FBI warned about teleconference hijacking and recommended host controls and restricted screen sharing as baseline protections. Google Meet encryption protects data in transit, but encryption alone doesn’t stop an unauthorized person from joining the call. These safety settings fill that gap.

What We Recommend

• Host management: ON. Only meeting hosts should control who can present and who gets muted.
• Media API: OFF, unless you have a specific, approved integration that requires it
• Review these settings quarterly as Google adds new Meet features

Where to Find It

Admin Console path: Apps > Google Workspace > Google Meet > Meet Safety Settings

📄 Google documentation: Manage Meet settings (for admins)

What Your Team Will Notice

Most of these changes happen in the background. Host management being on means meeting organizers have more control, which they generally appreciate. If you restrict screen sharing, participants who previously shared screens freely may need the host to grant them permission. This is a minor workflow change that most teams adjust to quickly.

Common Mistakes

• Leaving the Media API enabled by default. This is the most common misconfiguration we find in Meet settings. Unless you’re using a compliance recording service that requires API access, turn it off.
• Not testing after making changes. Meet settings interact with each other. After updating, run a test meeting to confirm your team’s normal meeting flow still works.
• Ignoring host management. Without host controls, any participant can mute others, kick people out, or lock the meeting. That’s fine for internal team calls, but risky for client-facing meetings with external participants.

Related Settings

• CHAT-025: Meet External Participant Controls. Controls who can join from outside your organization.
• CHAT-030: Meet Recording Controls. Who can record meetings?
• CHAT-035: Meet PSTN Dial-In Controls. Phone-based meeting access.

---

CHAT-025: Meet External Participant Controls Configured

What This Does

This setting controls how people outside your organization join Google Meet meetings. You can require external participants to request access, meaning they wait until the host lets them in. Or you can let them join directly from a calendar invite. You can also block external participants entirely. It also controls whether people who aren’t signed into a Google account can join.

Why It Matters

Every meeting with an external participant is a potential entry point. If your settings allow anyone with a meeting link to join without approval, a leaked or guessed link gives an outsider direct access to your conversation. They can listen in, see shared screens, and capture whatever is discussed.

This matters most for organizations that discuss sensitive topics in meetings: client financials, legal strategy, personnel issues, M\&A activity. For an RIA discussing portfolio details or a healthcare practice reviewing patient cases, an unauthorized attendee is a compliance violation, not just an embarrassment.

What We Recommend

• External participants: Require host approval (waiting room) before joining
• Anonymous participants (not signed into a Google account): Block or require host approval, depending on your needs
• Meeting access default: Set so that only invited people can join without asking, and everyone else goes to the waiting room
• For high-sensitivity meetings, consider blocking external participants entirely and using a separate meeting platform for client calls if needed

Where to Find It

Admin Console path: Apps > Google Workspace > Google Meet > Meet Safety Settings

📄 Google documentation: Manage meeting access settings for your users

What Your Team Will Notice

External participants will land in a waiting room and need the host to admit them. This adds a few seconds to the start of meetings with outside attendees. Meeting hosts will see a notification when someone is waiting to join. Internal participants (people in your Google Workspace domain) join normally without any extra steps.

Common Mistakes

• Allowing anyone with a link to join. This is the fastest path to a meeting intrusion. Meeting links get forwarded, shared in emails, and sometimes posted publicly. Don’t rely on link secrecy as your only access control.
• Setting strict controls but not training meeting hosts. If hosts don’t know to check the waiting room, external participants sit there confused while the meeting starts without them. Brief your team on how the waiting room works.
• Blocking external participants without warning. If your team regularly hosts clients or vendors in Meet, suddenly blocking external access will disrupt those meetings. Check who uses Meet with external contacts first.

Related Settings

• CHAT-020: Google Meet Safety Settings Configured. Broader meeting security controls.
• CHAT-035: Meet PSTN Dial-In Controls. Phone-based access is another path for external participants.
• AUTH-005: Two-Step Verification Enforcement. Authenticated participants are more trustworthy than anonymous ones.

---

CHAT-030: Meet Recording Controls Configured

What This Does

Google Meet allows meeting participants to record sessions. Recordings are saved to the organizer’s Google Drive. This setting controls who can record (everyone, or only meeting hosts) and whether recording is available at all. There’s also a separate compliance recording feature for regulated industries that automatically records all meetings for specific users.

Why It Matters

Meeting recordings capture everything: voice, video, screen shares, and chat messages during the meeting. That’s a lot of sensitive data sitting in someone’s Google Drive. If recording permissions are too broad, any participant (including external guests, in some configurations) could record a confidential discussion.

For regulated industries, the concern goes both ways. You may need recordings for compliance (FINRA requires retention of certain business communications), but you also need to control who creates them and where they’re stored. In Adelia Risk’s experience, most small firms haven’t thought about recording permissions at all. The default is usually “everyone can record,” which is too broad. An uncontrolled recording of a client meeting could end up shared, downloaded, or forgotten in someone’s Drive with no retention policy applied.

What We Recommend

• Restrict recording to meeting hosts and organizers. The default lets any participant record, which is too broad for meetings that include external guests or sensitive topics.
• Compliance recording: If you’re in a regulated industry (financial services, healthcare), evaluate Google Meet’s compliance recording feature. It can automatically record and retain meetings for specific users or groups.
• Recording storage: Make sure recordings are covered by your Drive DLP and Vault retention policies. They land in Google Drive, so your DRIVE-050: DLP rules and MON-055: Vault retention should apply.

Where to Find It

Admin Console path: Apps > Google Workspace > Google Meet > Meet Video Settings

📄 Google documentation: Turn Meet recording on or off for your organization

What Your Team Will Notice

If you restrict recording to hosts only, participants who previously had the option to record will no longer see the recording button. Hosts keep the ability. For most organizations, this is a non-issue since the host typically initiates recording anyway.

If you enable compliance recording for specific users, those users’ meetings will automatically start recording with a visible indicator. All participants will see that the meeting is being recorded.

Common Mistakes

• Allowing all participants to record. External guests could record your internal discussions. Restrict recording to hosts.
• Forgetting that recordings live in Drive. A meeting recording is a Drive file. If your Drive sharing settings allow external sharing, someone could share a recorded client meeting externally. Make sure your Drive security settings cover these files.
• Not applying retention policies to recordings. Meeting recordings can accumulate in Drive without any retention schedule. For regulated firms, this creates both storage and compliance problems.

Related Settings

• CHAT-020: Google Meet Safety Settings Configured. Broader meeting controls.
• DRIVE-050: DLP Rules Configured for Drive. DLP should cover meeting recordings stored in Drive.
• MON-055: Data Retention Configured (Vault). Retention policies for stored recordings.
• MON-005: Google Audit Logs Reviewed. Google Meet audit log data tracks who recorded which meetings.

---

CHAT-035: Meet PSTN Dial-In Controls Restricted

What This Does

Google Meet can include a phone number that lets participants dial in to a meeting using a regular phone (PSTN, or Public Switched Telephone Network). When dial-in is enabled, every meeting invitation includes a phone number and a PIN code. This setting controls whether dial-in is available and who can use it.

Why It Matters

Phone dial-in adds a second entry point to every meeting. Someone who gets the dial-in number and PIN can join the meeting audio without signing into Google, without being invited, and without going through the waiting room. That’s a gap in your meeting access controls.

For most modern organizations, phone dial-in is rarely needed. Team members join from their computers or phones using the Meet app. The main use case is for participants who don’t have reliable internet, which is increasingly uncommon. Honestly, we rarely see anyone using phone dial-in anymore. In our last 20 audits, maybe two organizations had a legitimate need for it.

What We Recommend

• If your team doesn’t use phone dial-in, turn it off. Fewer entry points means better meeting security.
• If some meetings need dial-in (field staff, international participants with poor internet): Enable it only for specific organizational units rather than organization-wide.
• If you must keep it on globally: Pair it with the waiting room controls from CHAT-025 so dial-in participants still need host approval.

Where to Find It

Admin Console path: Apps > Google Workspace > Google Meet > Meet Video Settings

📄 Google documentation: Set up Google Meet global dialing

What Your Team Will Notice

If dial-in is disabled, meeting invitations will no longer include a phone number. Participants who used to call in will need to join through the Meet app or a web browser. For most teams, this goes unnoticed because everyone already joins digitally.

Common Mistakes

• Leaving dial-in on “because it’s always been on.” Check your meeting usage data. If nobody has dialed in by phone in the last 90 days, turn it off.
• Disabling dial-in without telling the team. If one person on your team regularly dials in (maybe they have a long commute or work from a rural area), turning this off will surprise them. A quick check before disabling prevents that.

Related Settings

• CHAT-025: Meet External Participant Controls Configured. Waiting room controls work alongside dial-in restrictions.
• CHAT-020: Google Meet Safety Settings Configured. Overall meeting safety settings.

---

CHAT-045: Calendar Offline Access Disabled

What This Does

Google Calendar can sync data to a user’s device for offline access, letting them view their schedule when they don’t have an internet connection. When offline access is enabled, calendar data (event titles, attendees, descriptions, locations) is stored locally on the device. This setting controls whether offline access is available to your organization.

Why It Matters

Offline calendar access caches sensitive information on local devices. If a laptop is lost or stolen, the cached calendar data is accessible without needing to authenticate to Google. This includes meeting titles, attendee lists, descriptions, and any notes attached to events.

For most organizations, this is a minor risk because device encryption and screen locks provide a layer of protection. But for regulated industries or organizations handling sensitive client information, reducing the amount of cached data on endpoints is a good practice. Google’s Security Health page flags this as a recommended setting to review. We flag it during audits too, but it’s usually a lower priority than the other settings on this page. If your devices are encrypted and managed, the risk is minimal.

What We Recommend

• Disable offline access for organizations that handle sensitive calendar data (client meetings, patient appointments, deal discussions)
• Keep it enabled if your team frequently works in areas with unreliable internet, and your devices are properly encrypted and managed
• If you disable offline access, make sure your team knows they’ll need an internet connection to see their calendar

Where to Find It

Admin Console path: Apps > Google Workspace > Calendar > General Settings

📄 Google documentation: Manage Calendar for your users

What Your Team Will Notice

Users who relied on viewing their calendar offline (on planes, in areas with poor connectivity) won’t be able to see their schedule without internet access. The calendar will show a message that offline access isn’t available. For teams that work primarily in offices or areas with reliable internet, this change goes unnoticed.

Sample message to your team:

Hi team,

Starting \[date\], offline access for Google Calendar will be turned off. This means you’ll need an internet connection to view your calendar.

What you need to know:

1. If you’re connected to the internet (including phone data), nothing changes for you
2. If you sometimes check your calendar on a plane or in areas without service, you’ll want to screenshot your schedule ahead of time

This is a small change that reduces the amount of data stored on your device. Most people won’t notice any difference. Reach out to \[IT contact/helpdesk\] if you have concerns.

Common Mistakes

• Disabling offline access without considering mobile users. Some team members rely on their phone’s calendar in subway tunnels, on planes, or in rural areas. Ask before disabling.
• Leaving this as the only endpoint protection. Disabling the offline calendar is a small piece of device security. It doesn’t replace encryption, screen locks, or device management. Pair it with DEVICE-005: Mobile Device Management.

Related Settings

• DEVICE-015: Mobile Device Encryption Required. Device encryption protects all cached data, including the calendar.
• GMAIL-120: Gmail Web Offline Disabled. The same concept applies to email.

What These Settings Don’t Cover

Calendar, Chat, and Meet are just one piece of a full Google Workspace security configuration. Adelia Risk’s full benchmark covers 97 settings across eight areas:

• Authentication (MFA enforcement, password policy, passkeys, session controls)
• Gmail Security (email authentication, phishing protections, forwarding controls, encryption, DLP)
• Google Drive and Data Sharing (external sharing, shared drives, local sync, data loss prevention)
• Administrative Controls (admin account protection, inactive users, data regions, multi-party approval)
• Third-Party Apps and API (OAuth controls, Marketplace restrictions, Gemini, API access)
• Device and Mobile Management (MDM, device approval, endpoint verification, Chrome policies)
• Monitoring and Compliance (audit logs, alerting, data retention, Vault, Advanced Protection)

Each area has its own guide page with the same level of detail.

Need Help Configuring These Settings?

Some of these changes take five minutes. Steps to secure Google Meet (like disabling the Media API) or turning on external chat warnings are quick wins you can do right now. Others need more thought. Restricting Google Workspace calendar sharing, rolling out Chat DLP, and configuring compliance recording all require planning and communication with your team.

If you’re in a regulated industry (financial services, healthcare, government contracting), your Google calendar security settings and chat retention policies also have compliance implications. The settings you choose need to satisfy both your security goals and your regulatory requirements.

Adelia Risk provides Google Workspace security audits that review all 97 settings, deliver specific recommendations for your organization, and help you roll out changes without disrupting your team’s workflow.

Last verified: March 2026

Part of the Adelia Risk Google Workspace Security Benchmark, 97 controls across 8 security areas.