Security Setup Checklist

• Open the Admin consoleGoogle Cloud sign-in is managed in Google Workspace or Cloud Identity. Go to admin.google.com and sign in as an administrator.
• Find 2-Step Verification settingsIn the Google Admin console, go to Security > Authentication > 2-Step Verification.
• Turn on enforcementCheck 'Allow users to turn on 2-Step Verification' and set enforcement to On, choosing an enrollment grace period from 1 day to 6 months.
• Require security keys onlyUnder 'Methods', pick 'Only security key' so only hardware keys and passkeys are allowed. This blocks weaker codes that phishing can steal.
• Buy and register keysGive each admin a FIDO2 hardware key such as a Titan Security Key, then have them register it at myaccount.google.com under Security > 2-Step Verification.
• Protect admin accounts firstApply enforcement to an organizational unit or group that contains your administrators and users who touch sensitive data.
• Set backup keysHave each user register a second key so a lost key doesn't lock them out; store the spare in a safe place.

Evidence to keep: Screenshot of 2-Step Verification enforcement setting · List of users with security keys enrolled · Admin console audit log of the policy change

• Open IAMIn the Google Cloud console, go to IAM & Admin > IAM to see every person and service account and the roles they hold.
• Use predefined rolesWhen granting access, click 'Grant Access' and pick a narrow predefined role (like 'Storage Object Viewer') instead of broad roles like Owner or Editor.
• Check role recommendationsLook for the light-bulb recommendation icon next to a principal in IAM, or go to IAM & Admin > Recommendations to see where IAM Recommender suggests smaller roles.
• Apply the tighter roleClick the recommendation and apply it to swap an over-broad role for one that still covers what the user actually does.
• Create dedicated service accountsIn IAM & Admin > Service Accounts, make a separate service account for each app or workload so programs don't share one powerful identity.
• Lock down key creationIn IAM & Admin > Organization Policies, enforce the constraint 'Disable service account key creation' to stop risky downloadable keys.
• Review access regularlySet a monthly reminder to revisit IAM and Recommendations and remove any access that is no longer needed.

Evidence to keep: Export of IAM policy bindings per project · IAM Recommender history showing applied changes · Organization policy report on service account key constraints

• Open Asset InventoryIn the Google Cloud console, go to IAM & Admin > Asset Inventory to see all resources across your project, folder, or organization.
• Pick your scopeUse the scope selector at the top to view assets at the organization, folder, or project level so you see the full picture.
• Browse resource typesUse the Resources tab and filters to list VMs, buckets, and databases; click a resource's name to view its metadata.
• Review the hierarchyGo to IAM & Admin > Manage Resources (Resource Manager) to see the tree of organization, folders, and projects that groups everything.
• Export a snapshotUse the Export option in Asset Inventory (or the gcloud CLI) to save a point-in-time list to BigQuery or Cloud Storage for your records.
• Enable change trackingTurn on Asset Inventory feeds so you get notified when resources are created, changed, or deleted.
• List human and service accountsIn IAM & Admin > IAM and > Service Accounts, record who and what has access so people are inventoried too.

Evidence to keep: Exported asset list from Asset Inventory · Resource Manager hierarchy diagram or screenshot · List of all user and service accounts

• Open Logs ExplorerIn the Google Cloud console, go to Logging > Logs Explorer to search your logs; write a query and click Run query.
• Turn on Data Access logsGo to IAM & Admin > Audit Logs, pick the services you care about, and enable DATA_READ and DATA_WRITE logging (these are off by default).
• Confirm Admin Activity logsAdmin Activity audit logs are always on; verify you can see them in Logs Explorer so account and config changes are tracked.
• Route logs to a safe sinkIn Logging > Log Router, create a sink that sends logs to a locked Cloud Storage bucket or BigQuery for long-term retention.
• Activate Security Command CenterIn the console, go to Security > Security Command Center and activate it at the organization level to surface threats and misconfigurations.
• Set alertsIn Monitoring > Alerting, create alerting policies (for example on failed logins or IAM changes) so someone is notified fast.
• Protect the logsRestrict who can edit or delete log sinks and buckets so an attacker can't erase their own tracks.

Evidence to keep: Screenshot of enabled Data Access audit log config · Log Router sink pointing to retained storage · Security Command Center findings report

• Create a VPC networkIn the Google Cloud console, go to VPC network > VPC networks and click Create VPC network to build your private network.
• Add tiered subnetsWithin the VPC, create separate subnets for each tier (web, app, database) so functions are isolated by design.
• Write firewall rulesGo to VPC network > Firewall and create rules that deny by default and allow only needed traffic, targeting instances by network tags or service accounts.
• Set up Shared VPCIn VPC network > Shared VPC, designate a host project and attach service projects for centralized, consistent network control.
• Build a service perimeterGo to Security > VPC Service Controls, click Manage access policies, and create a perimeter around projects so data can't leak to outside services.
• Add host and service projectsWhen using Shared VPC, add both the host project and the service projects to the perimeter so the whole boundary is covered.
• Test then enforceRun the perimeter in dry-run mode first to see what it would block, then switch to enforced once it looks correct.

Evidence to keep: VPC and subnet configuration export · Firewall rule list showing default-deny · VPC Service Controls perimeter configuration

• Enable VM ManagerIn the Google Cloud console, go to Compute Engine > VM Manager and enable the OS Config service so agents can inspect your VMs.
• Turn on OS inventoryEnsure the OS Config agent is installed and OS inventory is enabled so each VM reports its installed packages.
• Review vulnerability reportsIn Compute Engine > VM Manager > Vulnerability reports, view the CVEs (Common Vulnerabilities and Exposures) found on your machines.
• Create patch jobsIn VM Manager > Patch, create a patch deployment to update Windows and Linux VMs on a schedule instead of by hand.
• Scan container imagesTurn on Artifact Analysis in Artifact Registry so container images are automatically scanned for known vulnerabilities.
• See it all in SCCGo to Security > Security Command Center to view VM and container findings across all projects in one dashboard.
• Prioritize and fixSort findings by severity in SCC and patch the critical and high items first, tracking each to closure.

Evidence to keep: VM Manager vulnerability report export · Patch deployment job history · Security Command Center findings list with remediation status

• Open Key ManagementIn the Google Cloud console, go to Security > Key Management to manage your encryption keys.
• Create a key ringClick Create key ring, give it a name, and choose a location that matches the region of the data you'll protect.
• Create a keyInside the key ring, click Create key to make a CMEK, and set a rotation period so the key changes automatically over time.
• Grant the service accountGive the resource's service account the role 'Cloud KMS CryptoKey Encrypter/Decrypter' on that key so it can use it.
• Attach CMEK to resourcesWhen creating a bucket, disk, or database, choose 'Customer-managed encryption key' and select your CMEK.
• Confirm default encryptionRemember Google already encrypts all data at rest by default; CMEK adds your own control on top for sensitive workloads.
• Enforce encryption in transitRequire TLS (HTTPS) for connections and enable 'Enforce SSL' options so data is protected while moving between systems.

Evidence to keep: Cloud KMS key ring and key configuration · Resource settings showing CMEK enabled · Key rotation schedule record

• Open Backup and DRIn the Google Cloud console, go to Backup and DR to reach the data protection interface.
• Create a backup vaultCreate a backup vault as an isolated, protected storage destination, and choose a region or multi-region location for resilience.
• Define a backup planCreate a backup plan setting the frequency, retention period, and the backup vault where copies are stored.
• Protect your VMs and disksApply the backup plan to your Compute Engine instances and Persistent Disks (or use the default backup plan) so they are captured automatically.
• Add snapshot schedulesIn Compute Engine > Snapshots, attach a snapshot schedule to disks for simple, low-cost automated backups into your chosen region.
• Store copies in another regionUse multi-region vaults or multi-region snapshot storage so a single region outage doesn't take your backups with it.
• Test a restorePeriodically restore a backup into a test environment to prove the copies actually work before you need them.

Evidence to keep: Backup plan and vault configuration · Snapshot schedule showing recent successful backups · Documented restore test results

• Activate SCC at org levelIn the Google Cloud console, go to Security > Security Command Center and activate it at the organization level to enable the security posture service.
• Apply a CIS posture templateIn Security Command Center > Posture, deploy the predefined CIS Google Cloud Benchmark posture template to detect settings that don't meet the standard.
• Set organization policiesGo to IAM & Admin > Organization Policies and enforce constraints (like disabling public IPs or service account keys) to prevent risky configurations.
• Review Security Health AnalyticsIn Security Command Center, check the Security Health Analytics findings for misconfigurations across your projects.
• Deploy postures by scopeApply postures at the organization, folder, or project level so the right baseline covers the right resources.
• Fix driftWork through the findings and correct each resource that has drifted from the baseline, then re-check that it clears.
• Monitor continuouslyKeep the posture active so new violations are flagged automatically instead of only at audit time.

Evidence to keep: Security posture definition and compliance report · Organization policy constraint settings · Security Health Analytics findings showing resolved items

• Open Sensitive Data ProtectionIn the Google Cloud console, go to Security > Sensitive Data Protection to reach the scanning and de-identification tools.
• Run a discovery scanCreate an inspection or discovery job to scan Cloud Storage and BigQuery for sensitive data using the built-in detectors (150+ types).
• De-identify sensitive fieldsUse de-identification templates to mask or tokenize sensitive values before data is used to train or prompt AI models.
• Secure Vertex AI accessIn Vertex AI, restrict access with IAM roles and put Vertex AI resources inside a VPC Service Controls perimeter to stop data leaving.
• Filter AI inputs and outputsRoute prompts and responses through Sensitive Data Protection (or Model Armor) so sensitive text is caught in both directions.
• Turn on audit loggingEnable Cloud Audit Logs for Vertex AI so every model and data access is recorded for review.
• Set an AI use policyWrite a simple rule for staff on what data may and may not be sent to AI tools, and train the team on it.

Evidence to keep: Sensitive Data Protection scan results and de-id templates · VPC Service Controls perimeter covering Vertex AI · Vertex AI audit logs and written AI use policy