Learn
Guide
Google Workspace’s native alert system can flag suspicious device activity, forced user suspensions from suspicious logins, government-backed attack attempts and phishing emails. Depending on your edition, admins can also write their own reporting rules on log events, such as a Drive file being made visible on the web. Even so, the defaults are reactive, and they miss insider threats, risky file-sharing patterns and third-party app access that quietly accumulates over time. Catching suspicious access before it becomes an incident means layering your own alert rules, log review habits and access governance on top of what Google ships by default.
TL;DR
Google Workspace’s default alerts (suspicious devices, suspicious-login suspensions, phishing, government-backed attacks) are a baseline, not a full detection system.
Reporting rules in the admin console let you alert on log events you care about, such as a Drive file being made visible on the web, and the alerts land in the alert center.
The Google Workspace audit log is the raw material for real detection, but it needs regular review and correlation, not just storage.
Compliance frameworks like the NIST Cybersecurity Framework and SOC 2 expect ongoing monitoring for anomalous activity, which is a stricter bar than Google’s defaults.
Oversharing, scope creep from third-party apps and dormant admin accounts are the gaps native alerts tend to miss.
A platform purpose-built for Google Workspace can give you app and OAuth scope visibility and automatic access removal, without hiring a dedicated IT or security person.
What Does Google Workspace Alert You About By Default?
Google Workspace’s built-in alert center generates alerts for a set of events out of the box, and understanding that list is the first step to knowing where your gaps are. Verified examples include suspicious device activity, user suspensions triggered by suspicious activity, government-backed attack warnings, user-reported phishing and phishing messages detected after delivery.
These alerts exist because Google’s systems are tuned to catch patterns that look like credential theft or nation-state targeting. They are not tuned to understand your organization’s specific roles, your sensitive data locations or what “normal” looks like for a given employee. A finance lead downloading an unusual volume of files at 2 a.m. might never trip a native alert if the login itself looks legitimate.
Workspace is a productivity platform first, and its security alerting reflects a general-purpose baseline meant to apply to every customer, from a five-person team to a multinational. Closing the gap between that baseline and your actual risk profile is the job of reporting rules, audit log review and access governance, covered below.
Why Isn’t the Default Alert Set Enough on Its Own?
The predefined alerts are generic, which means they miss the categories of risk that tend to precede real incidents: oversharing, insider misuse, third-party app scope creep and admin accounts nobody uses anymore. Anything outside the patterns Google has already modeled passes through silently unless you add a rule for it.
Four gaps show up repeatedly in practice:
Oversharing and file exposure. A file set to “anyone with the link” doesn’t look like a login anomaly, so the predefined suspicious-activity alerts won’t flag it. A reporting rule on file-visibility events can, as covered in the next section.
Insider threats and slow-moving access abuse. An employee gradually expanding their access to folders outside their role, or an offboarded contractor whose account wasn’t fully revoked, won’t match any phishing or device-risk signature.
Third-party app permissions. OAuth-connected apps can retain broad scopes to Workspace data long after anyone remembers granting them, and Google’s default alerting doesn’t flag scope creep from apps that were legitimately approved at install time.
Dormant admin accounts. An admin account that nobody uses anymore keeps its privileges and looks like normal, quiet activity, so nothing in the default alert set calls it out.
Google’s predefined alerts are a starting point. They assume the organization is also writing its own rules and doing log review, access audits and app permission checks.
How Do Reporting Rules Let You Alert on Your Own Events?
Reporting rules are the most direct way to turn the audit log into alerts tuned to your risk. In the admin console, go to Rules, then Create rule, then choose Reporting. A reporting rule watches log events and fires an alert when a condition you define is met. For example, you can alert when a Drive file is made visible on the web.
Triggered alerts land in the alert center, alongside Google’s own, so there is one place to review them. Depending on your edition, admins can write their own reporting rules. Premium editions also get activity rules.
That makes the oversharing gap above fixable without any extra tooling: write a rule for the sharing events that would worry you, and the alert center tells you when one happens. Start with the one or two events you would most regret missing, then add more as you learn which alerts are worth acting on.
What Else Should You Configure in the Admin Console?
Beyond reporting rules, a few other settings make a disproportionate difference:
Control | What to configure | Why it matters |
|---|---|---|
Context-aware access | Restrict access to Workspace apps and services by context such as device and location (requires an eligible edition) | Adds a device and location check on top of a correct password, so access from an unmanaged device or unexpected location can be treated differently |
Alert center notifications | Review the alert rules available in your admin console and turn on notifications for the ones that matter to your risk profile | Many admins don’t realize these are configurable options, not just passive logs |
File-sharing audits | Periodically review org-wide and public sharing settings | Surfaces exposure that never generates a login-based alert |
Data governance and retention policies | Review Vault retention and DLP rules on a set schedule rather than ad hoc (edition-dependent) | Keeps policy aligned with where sensitive data actually lives as the org grows |
Context-aware access is worth singling out. It works like a bouncer checking more than the name on the ticket: it evaluates context such as device and location before letting someone into Workspace apps and services, so the same correct password can be treated differently from an unmanaged personal laptop than from a company laptop on a known network. It is not available on every plan. It requires Enterprise Standard or Plus, Frontline, Education Standard or Plus, Enterprise Essentials Plus or Cloud Identity Premium, and it is not part of the Business editions. Vault and DLP controls are also tied to edition, so check what your plan includes before you build a process around them.
How Does the Google Workspace Audit Log Fit Into This?
The audit log is the underlying record that makes any of this detection possible. The Google Workspace logs capture admin actions, login events, file access and sharing changes across the domain, and they’re the data source both Google’s native alerts and any third-party monitoring tool draw from.
Retention matters here. Admin, user, Drive and OAuth log events are kept for 6 months, and that window can’t be extended. Anything older than that is gone from the admin console, so a suspicious pattern you only notice after the window closes can’t be investigated from Google’s logs alone.
The problem most small teams run into isn’t a lack of logging. It’s that nobody is reviewing the logs on a regular cadence, so by the time someone checks after a report of strange behavior, the suspicious pattern may already be an incident.
A useful way to think about it: the audit log is a security camera, but a camera recording to a hard drive nobody watches isn’t a security system, it’s a backup for an investigation. Turning the log into an actual early-warning system requires someone (or some platform) regularly asking “does this pattern match what we’d expect from this role, this employee, this time of day.”
What Do Compliance Frameworks Expect That Google’s Defaults Don’t Cover?
NIST and SOC 2 both expect ongoing monitoring for anomalous activity.
That’s a materially higher bar than “Google emails me if there’s a government-backed attack.” In practice it implies:
A defined, documented picture of normal access per role
Alerting on deviations, not just Google’s predefined alerts
Regular review of the logs behind those alerts
An audit trail that can be produced on demand during a review
Meeting that bar with spreadsheets and manual log checks is possible at a handful of employees. It stops being realistic once access setup, SaaS spend, app permissions and incident response all need watching, because nobody has a single view of what “normal” looks like across all of them at once.
How Can You Close These Gaps Without Hiring a Security Team?
A dedicated security hire is rarely realistic at startup or small-business scale. ShiftControl was built around that exact constraint: made for Google Workspace, so a founder or ops lead gets the control a large company has.
In practice, that means:
Automatic access setup and removal. Google Workspace access is set up and removed automatically, and everything else runs as a guided task list for the app owner, which helps with the gap of an offboarded contractor whose account wasn’t fully revoked.
App and OAuth scope visibility. See every app and OAuth scope connected to your Workspace, addressing the scope-creep problem directly.
SaaS spend management in the same dashboard, so app sprawl (a precursor to shadow-app risk) is visible alongside access data.
Incident response included in the subscription. Cyber incident response (IR-1, via Blackpanda) is included in every subscription, rather than sold as a costly add-on after something has already gone wrong.
Setup takes as little as 10 minutes: sign in with Google Workspace admin single sign-on and you can start seeing your users, groups and connected apps.
Frequently Asked Questions
Does Google Workspace have a built-in audit log?
Yes. Google Workspace logs admin actions, login events and file activity, accessible through the admin console. Reviewing it regularly, not just storing it, is what turns it into a detection tool. Admin, user, Drive and OAuth log events are kept for 6 months.
Can I create my own alerts in Google Workspace?
Yes. In the admin console, go to Rules, then Create rule, then Reporting. You can alert on log events such as a Drive file being made visible on the web, and the alerts land in the alert center. Depending on your edition, admins can write their own reporting rules, and premium editions also get activity rules.
What’s the difference between Google’s native alerts and third-party monitoring?
Native alerts and reporting rules cover the events Google logs and the conditions you define. Third-party tools can add role-based baselines, app-permission visibility and cross-platform context that Google’s defaults don’t include.
Can small businesses meet SOC 2 or NIST monitoring expectations without a security team?
It’s possible, with the right tooling. The frameworks expect ongoing monitoring and a response to anomalous activity, not a minimum headcount. Tools purpose-built for Google Workspace can take on part of that work without an IT hire.
Is ShiftControl a replacement for Google Workspace’s admin console?
No. ShiftControl is a separate platform purpose-built for Google Workspace, with its own admin access, that adds access setup, spend management, app and OAuth scope visibility and incident response on top of what Google provides.
Is incident response an extra cost with ShiftControl?
No. Cyber incident response (IR-1, via Blackpanda) is included in every subscription, not a separate add-on.
How does ShiftControl’s pricing work?
Standard pricing is $10 per user per month, billed yearly, with everything included. Startups get $2 per user (80% off your first 10 seats for the first year) and non-profits have special pricing, so talk to us. You can also start a 14-day free trial with no credit card required.
About ShiftControl
ShiftControl is an IT operations and SaaS management platform made for Google Workspace, built for the non-technical operator, no IT team required. It brings access setup, SaaS spend tracking, app-permission visibility and incident response into one platform. ShiftControl is SOC 2 Type 2 compliant, ISO 27001 certified and signed the CISA Secure by Design Pledge in 2024. Its partnership with Blackpanda means every subscription includes real incident response, not a bolt-on upsell.
If native Google Workspace alerts are the only thing standing between your business and a slow-building incident, it’s worth seeing what ShiftControl adds on top of them. Book a demo or start a 14-day free trial, no credit card required.
