Google Workspace Security Baseline for Small Organizations

Direct answer: A small-organization Google Workspace baseline begins with resilient administration and enforced 2-Step Verification, then controls Gmail threats, Drive sharing, third-party apps, devices, alerts, and recovery. Maintain more than one protected administrator, use separate daily and privileged accounts, prefer phishing-resistant authentication for high-risk users, limit external sharing and OAuth access, and route important alerts to someone who will act. Validate the settings in your own edition and tenant; product controls and licensing change.

This guide is written for a small organization that needs an accountable operating process, not a vague list of best practices. It is grounded in SCuBA Google Workspace Secure Configuration Baselines and cross-checked against Google Workspace Security Checklists. Product interfaces, licensing, threats, and legal obligations can change, so verify current provider documentation and obtain qualified legal or regulatory advice when the decision requires it.

Make the baseline product-specific: Google Workspace security best practices begin with administrator resilience, enforced 2-Step Verification, and clear organizational-unit scope. In the Google Admin console, document every permission, exception, and edition dependency. Keep multiple protected admin accounts, disable unused access, and test recovery so one lost device or compromised administrator does not become a full tenant breach.

A Google Workspace security baseline should cover Gmail email security, Google Drive sharing, OAuth applications, endpoint controls, alert routing, and sensitive data handling. Built-in security features can reduce security risks, but they do not eliminate unauthorized access or replace data protection decisions. Review the security posture after domain, app, identity, or sharing changes, and confirm each control in the live tenant rather than treating general SaaS security guidance as proof of configuration.

Build resilient administration

Keep at least two appropriately protected super-administrator accounts controlled by different authorized people or recovery paths. Do not use a super-admin identity for daily email and browsing. Assign narrower administrator roles for routine work, inventory role assignments, and promptly remove stale access. Protect recovery information from being controlled by the same account it is meant to recover.

Enforce 2-Step Verification, prioritizing administrators, finance, executives, and other sensitive users. Google identifies security keys as a strong phishing-resistant method. Plan enrollment, backup methods, replacement, travel, and lost-device handling. Use organizational units or groups for a controlled rollout and verify enforcement rather than assuming an announcement changed behavior.

Harden Gmail and domain trust

Configure protections against spoofing, phishing, malware, and suspicious attachments according to the tenant's needs. Review routing, forwarding, delegation, filters, allowlists, and third-party gateways. Monitor changes that can silently redirect or expose mail. Train staff to use the built-in reporting path and give security or IT a process for investigating reports.

Set up and maintain SPF, DKIM, and DMARC for organizational domains and legitimate senders. Email authentication reduces domain impersonation risk but does not make every authenticated message trustworthy. Track third-party senders, remove obsolete services, and review aggregate reports or equivalent evidence. Changes should be tested to avoid blocking legitimate business mail.

Control Drive, apps, and devices

Choose external-sharing defaults based on data sensitivity and collaboration. Review publicly accessible files, link-sharing, shared drives, external members, ownership, and stale access. Prefer shared drives for organizational records where governance needs justify them. Define how departing-user data and shared resources are transferred.

Review Marketplace applications, OAuth grants, API access, and service accounts. Restrict untrusted apps and approve high-risk scopes only with a business owner and evidence. Apply endpoint, mobile, screen-lock, encryption, supported-version, and remote-account-removal controls as available and appropriate. Personal devices need explicit data-access rules rather than an informal exception.

Monitor and recover

Configure alerting for suspicious sign-ins, administrator changes, unusual sharing, account compromise, and security-setting changes. Route high-priority events to a monitored group and test the workflow. Retain and export logs according to investigation and legal needs. Know which reports depend on the Workspace edition.

Create a compromised-account runbook: suspend the user when appropriate, revoke sign-in cookies and tokens, reset credentials and 2SV, inspect recovery details, forwarding, delegation, filters, OAuth grants, Drive sharing, and administrator activity, then communicate through a trusted channel. Exercise a super-admin recovery and a departing-user transfer. Document evidence and unresolved dependencies.

Implementation sequence and evidence

Use the following sequence as a working control record. Assign one accountable owner per step, keep the evidence in a location responders can reach, and date each artifact. A checkbox without evidence is only an assertion. Where a step changes production, use the organization’s change, backup, rollback, and approval process.

1. Inventory administrators. Export super admins, delegated roles, service accounts, and recovery owners. Evidence: Dated assignments with business justification.
2. Enforce 2SV. Roll out strong 2-Step Verification with recovery and replacement procedures. Evidence: Enrollment and enforcement report.
3. Protect Gmail. Review spoofing, malware, routing, forwarding, delegation, and allowlists. Evidence: Policy evidence and controlled test.
4. Authenticate domains. Maintain SPF, DKIM, DMARC, and an inventory of legitimate senders. Evidence: DNS records, authentication result, and owner.
5. Constrain sharing. Set defaults and review public, link, external, and stale access. Evidence: Drive sharing report and exceptions.
6. Govern apps. Review OAuth scopes, Marketplace apps, APIs, and service accounts. Evidence: App inventory with owner and approval.
7. Route alerts. Send priority events to a monitored group and escalation path. Evidence: Test alert and acknowledgment time.
8. Exercise recovery. Test compromised-account and admin-recovery runbooks. Evidence: Timeline, artifacts, gaps, and fixes.

How to verify the control is operating

Verification should sample the saved state and the real workflow. Review configuration or inventory evidence, trigger a controlled event where safe, confirm the responsible person receives and understands it, and inspect the resulting record. For higher-impact controls, have someone other than the implementer review closure. Recheck after material changes rather than relying indefinitely on the first successful test.

• Inventory administrators: confirm the owner can produce dated assignments with business justification and explain any exception.
• Enforce 2SV: confirm the owner can produce enrollment and enforcement report and explain any exception.
• Protect Gmail: confirm the owner can produce policy evidence and controlled test and explain any exception.
• Authenticate domains: confirm the owner can produce dns records, authentication result, and owner and explain any exception.
• Constrain sharing: confirm the owner can produce drive sharing report and exceptions and explain any exception.
• Govern apps: confirm the owner can produce app inventory with owner and approval and explain any exception.
• Route alerts: confirm the owner can produce test alert and acknowledgment time and explain any exception.
• Exercise recovery: confirm the owner can produce timeline, artifacts, gaps, and fixes and explain any exception.

Record scope as carefully as the result. State which tenants, systems, locations, users, suppliers, or versions were examined; the time window; the method; and any blind spots. This makes a later reviewer less likely to mistake a narrow sample for organization-wide assurance.

Common failure modes

One super admin

Loss or compromise of one account can become a tenant-wide crisis. Maintain controlled redundancy and tested recovery.

2SV without recovery planning

Users bypass controls or administrators get locked out. Plan methods, backup, replacement, and help-desk verification.

Open link sharing

Sensitive files can remain accessible after the original collaboration ends. Review links and external membership.

Password reset only

Compromise may persist through sessions, recovery data, delegation, forwarding, or OAuth tokens. Inspect and revoke each path.

Questions teams ask

Are security keys required?

Google recommends security keys as a strong method, especially for high-risk users. Choose authentication methods based on risk, compatibility, and recovery needs.

Can a small business use the CISA SCuBA baseline?

Yes, as a reference. Tailor recommendations to the organization's edition, risk, operational capacity, and legal obligations, and validate current product behavior.

Does Google Workspace back up all data for every recovery scenario?

Service availability, retention, restore, Vault, and independent backup are different questions. Define recovery requirements and test the chosen approach.

Ownership, cadence, and documentation

Name a Workspace business owner, a primary security administrator, and more than one protected super administrator. Use separate daily and privileged accounts, secure recovery paths outside the tenant where appropriate, and document who can contact Google or a reseller during account recovery. A service provider may administer settings; the organization still owns access, exceptions, and continuity.

Keep a baseline record for the exact organizational units and groups in scope. For each setting, capture the Admin console path or policy identifier, configured value, edition dependency, exclusions, owner, date, validation result, and next review. Preserve before-and-after evidence for changes and restrict exports that reveal users, groups, routing, or security configuration.

Review alert-center events and administrator activity on an operating cadence, then perform a structured baseline review at least quarterly and after edition, domain, identity, app, or sharing changes. Test 2-Step Verification enforcement, a standard user, a privileged user, external Drive sharing, a controlled OAuth request, alert routing, and administrator recovery without depending on one person or device.

Related EncryptCentral fundamentals

Use these implementation steps with the site’s existing explainers on multifactor authentication fundamentals and cloud storage security. Those pages cover the underlying concepts; this guide is the operating layer for ownership, evidence, and verification.

Decision

Adopt the smallest version of this process that changes a real decision, names an owner, and produces reviewable evidence. Expand it when risk, complexity, or obligations justify more control. Do not confuse a purchased tool, written policy, completed questionnaire, or successful job message with an operating outcome. The durable result is a verified change, an understood exception, and a next review date.

Primary references

• SCuBA Google Workspace Secure Configuration Baselines — CISA
• Google Workspace Security Checklists — Google
• Protect Your Business with 2-Step Verification — Google