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. We’ve also added a heads-up on Google’s new Workspace Guest
Accounts feature (CHAT-055) — rolled out in 2026
and worth reviewing if your team collaborates with non-Workspace
users.
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-055 | Google Workspace guest accounts | 🟡 Medium | Yes | Security > Access and data control > External sharing |
| 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)
Risk: 🟠 High | Heads Up? No
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.
The FBI’s
Internet Crime Complaint Center reported $16.6 billion in cybercrime
losses in 2024, with cyber-enabled fraud and business email
compromise among the costliest categories. The report doesn’t break out
messaging-specific incidents, but the scale of losses underscores why
every communication channel, including Chat, needs monitoring.
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. Same concept applied 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
Risk: 🟡 Medium | Heads Up? Yes
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.
Relevant to: SEC recordkeeping rules (17a-4), FINRA communications
supervision, HIPAA audit trail requirements.
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:
- You’ll see a “History is on” indicator in your chats
- Messages will be searchable and retained according to our data
retention policy - 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
Risk: 🟡 Medium | Heads Up? Yes
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 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.
If your organization doesn’t actively use Chat Apps for a specific
business purpose, turning them off removes the risk entirely. In most
Adelia Risk audits, Chat Apps are either disabled or nobody is using
them anyway. That’s the right call for most small and mid-sized
businesses.
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:
- Any Chat bots you currently use will stop working
- You won’t be able to install new Chat Apps
- 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
Risk: 🟡 Medium | Heads Up? Yes
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
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.
For organizations where external chat is genuinely needed, the risk
calculation changes, but the controls still matter. Unrestricted
external chat means anyone with a Google account can message your
employees. Restricting external chat to trusted domains narrows that
exposure significantly, limiting conversations to known partners,
vendors, or clients.
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-055: Google Workspace Guest Accounts.
Guest accounts are only provisioned when external chat is enabled.
CHAT-055: Google Workspace Guest Accounts
Risk: 🟡 Medium | Heads Up? Yes
What This Does
Google Workspace Guest Accounts is a new way to bring non-Workspace
users (people using Microsoft 365, Outlook, or any other email system)
into Google Chat and Drive collaboration without giving them a full
Google Workspace license. When someone on your team invites an external,
non-Workspace contact to a Chat direct message or Space, Google
provisions a unique “guest account” for that person inside your domain.
The guest can then participate in Chat conversations and edit Docs,
Sheets, and Slides that you share with them.
Guest accounts started rolling out broadly in March 2026 and are
generally available in all Business and Enterprise SKUs. You get five
free guest accounts for every paid Workspace license, so a firm with 20
licenses can host up to 100 guests. Guests cannot create or own new
Drive files, do not get Gmail, Calendar, or Gemini, and live in a
dedicated “Workspace Guests” Organizational Unit (OU) in your Admin
Console.
Why It Matters
Bringing external collaborators into your domain is a real
improvement over emailing files around or using a side-channel chat app.
You get the audit trail, the DLP rules, and the Vault retention you
already configured for internal users. That’s the upside.
The downside is that guest accounts are real accounts inside your
directory. They show up in the Workspace Guests OU. They count against
your security posture. And because they’re auto-provisioned the moment
an employee invites someone, your directory can fill with stale guests
from finished projects unless you actively prune them.
Google does the right thing on a few critical defaults. Guest
accounts start with no directory visibility, no third-party app access,
and no SSO. Those settings do not inherit from your
top-level OU, so even an organization with permissive Root OU policies
gets a reasonable baseline for guests out of the box. But most other
settings (DLP, Context-Aware Access, Vault retention)
do inherit from your top-level OU unless you override
them on the Workspace Guests OU. Don’t assume — verify which settings
inherit and which are overridden before you trust the defaults.
One more thing worth knowing: turning off the guest accounts feature
does not remove existing guests. Internal users lose the ability to
invite new guests, but the guests already provisioned keep their
accounts and their access to files until an admin manually deletes
them.
What We Recommend
- Lock down the Workspace Guests OU. Review every
service setting and security policy on this OU. The defaults that don’t
inherit (directory visibility, third-party app access, SSO) are
sensible. The ones that do inherit (DLP, Context-Aware Access, Vault
retention, 2-Step Verification) need explicit policies. Treat this OU
like a contractor population, not like internal staff. - Restrict who can invite guests. By default, if
external chat is enabled, every user can send guest invitations. For
firms handling regulated or sensitive data, narrow this to a vetted
group (project managers, IT, partners) through Security > Access
and data control > External sharing > Guest invitations. - Use allowlisted domains where you can. If you only
work with a known set of outside firms, add their domains to your
allowlist. One caveat: allowlisting prevents collaboration with consumer
Google accounts created against work email addresses, which can surprise
users who are used to ad-hoc external sharing. - Establish a quarterly lifecycle review. Open
Directory > Guests in the Admin Console every quarter and
delete guests tied to finished projects. Guest accounts cannot be moved
to other OUs, so removal is the only cleanup path. Without this, you end
up with hundreds of orphaned accounts retaining access to historical
Chat history and Drive files. - Decide what gets shared in guest-accessible Spaces.
Chat Space history is on by default. The moment you add a guest to an
existing Space, that guest can read every message and file that was ever
posted there. If a Space contains sensitive history, start a new Space
for the guest instead of inviting them into the old one.
Where to Find It
Admin Console path (invitation controls): Security
> Access and data control > External sharing > Guest
invitations
Admin Console path (Workspace Guests OU): Directory
> Organizational units > Workspace Guests
Directory management: Directory > Guests
📄 Google documentation: Manage Workspace
guests
What Your Team Will Notice
Guest accounts are marked with a teal “External”
badge next to the person’s name in Chat. This is different from
the yellow “External” badge that flags external users
who have their own Google Workspace account. The two badges look similar
at a glance — train your team to notice which color they’re seeing
before sharing anything sensitive.
Sample message to your team:
Hi team,
Starting [date], we’re enabling Google Workspace
Guest Accounts. This lets you collaborate with partners and clients who
don’t use Google Workspace (Microsoft 365, Outlook, or any other email
system) directly inside Google Chat and Drive.
What you need to know:
- You can invite an external contact to a Chat DM or Space, and
they’ll get an invitation to create a guest account in our domain. - Guests are marked with a teal “External” badge.
External users who already have their own Google Workspace will show a
yellow “External” badge. Different badges, different
account types. - Guests can read Chat history. When you add a guest to an existing
Space, they can see every message and file already posted in it. If the
Space has sensitive history, start a new Space for the guest. - Guests can edit Docs, Sheets, and Slides you share, but they can’t
create new files or use Gmail, Calendar, or Gemini.
This makes external collaboration faster and keeps the conversation
inside our security and retention controls. Reach out to [IT
contact/helpdesk] with questions or to request a guest
invitation if your role doesn’t have it enabled.
Common Mistakes
- Treating the Workspace Guests OU like any other OU.
Most settings inherit from your top-level OU unless you override them.
The few that don’t (directory visibility, third-party apps, SSO) are
sensible defaults, but the rest still need explicit policies. Don’t
assume guests are sandboxed just because they’re in their own OU. - Confusing guests with external Workspace users. A
teal badge and a yellow badge look similar but mean very different
things. External Workspace users have their own corporate security
controls; guest accounts are often tied to personal email providers with
no security oversight at all. - Never cleaning up. Guest accounts are created
automatically. Without a quarterly review, your directory will fill with
accounts for projects that ended a year ago, still retaining access to
old Chat Spaces and Drive files. And remember: disabling the guest
feature does not delete existing guests. - Inviting guests into Spaces with sensitive history.
Chat history is on by default, and adding a guest exposes everything
ever said in that Space. If you’re bringing a new vendor or client in,
start a fresh Space. - Allowlisting domains without thinking through the side
effects. A domain allowlist will block guest invitations to
anyone whose email is on a non-allowlisted domain, including consumer
Google accounts created against work email addresses. Useful for
sensitive firms; surprising for everyone else.
Related Settings
- CHAT-015: External Chat Restrictions.
Controls whether users can chat with people outside your organization at
all. Guest accounts only exist when external chat is enabled. - CHAT-025: Meet External Participant Controls
Configured. Governs how external participants (including guests)
join Google Meet calls. - CHAT-005: Chat History Settings Configured.
Determines whether a guest joining a Space sees prior message
history. - CHAT-050: DLP Rules Configured for Chat. DLP
scans messages sent to guests the same way it scans internal messages,
as long as you apply the rule to the Workspace Guests OU.
CHAT-020: Google Meet Safety Settings Configured
Risk: 🟡 Medium | Heads Up? No
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.
The most common issue we find in Meet settings is the Media API left
enabled. The Media API lets third-party applications capture meeting
streams. Unless you’re using a specific integration that requires it
(like a compliance recording tool), this should be off.
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
Risk: 🟡 Medium | Heads Up? No
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.
Adelia Risk checks this in every Meet review. Most organizations
leave it on the default, which is more permissive than they realize.
CISA’s Secure Cloud Business Applications (SCuBA) baseline recommends
restricting meeting access to authenticated users as part of Google Meet
privacy settings. The extra 5-second step of admitting someone from the
waiting room is a small price for knowing exactly who’s in the room.
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
Risk: 🟡 Medium | Heads Up? No
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.
The CIS Google Workspace Foundations Benchmark recommends restricting
recording to meeting hosts and organizers.
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
Risk: 🟢 Low | Heads Up? No
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.
The risk is limited compared to other settings on this page, but
closing unnecessary access paths is good practice.
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
Risk: 🟢 Low | Heads Up? Yes
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.
The risk level is low because exploiting this requires physical
access to an unlocked or decrypted device. But combined with other
device security gaps (like missing endpoint encryption per DEVICE-015),
it can become a real exposure.
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:
- If you’re connected to the internet (including phone data), nothing
changes for you - 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, planes, or rural areas. Ask before disabling. - Leaving this as the only endpoint protection.
Disabling 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 calendar. - GMAIL-120:
Gmail Web Offline Disabled. Same concept applied 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.
