The Centurion Scenario: A Password Changed in Haste, a Reporting Pipeline Gone Quiet
Picture a mid-sized e-commerce brand on the outskirts of Centurion. A marketing manager resigns on a Friday. By Monday the remaining team has changed the shared Google login password - the same login that owns Google Ads billing, GA4 property admin, and the GTM container. Nobody screenshotted anything first. Two days later the paid team notices conversions reported by Google Ads no longer match GA4, and a Tag Manager integration has silently stopped firing. No one can say which change caused it.
That sequence - not the password change itself - is the problem this runbook solves. This is a credential-rotation procedure for marketing teams, focused on the moment of rotation and the checks most teams skip afterwards.
A password change is a security event with commercial side effects. Treat it as a controlled change, not a panic response.
What a Google Password Change Actually Does - and What It Leaves Untouched
Three facts matter, and all three surprise teams:
- Changing your password does not sign you out of every device by default. Google exposes a separate control for reviewing devices and signing out of all sessions.
- Changing your password does not revoke third-party OAuth access you previously granted at
myaccount.google.com/connections. Those tokens keep working until you remove them. - Google Ads has no separate password. It rides on the Google Account, so the account password and 2-Step Verification are the real security controls for your ad account.
Consumer Gmail vs Google Workspace .co.za: Two Different Password-Change Routes
| Dimension | Consumer Gmail | Google Workspace (.co.za domain) |
|---|---|---|
| Who changes the password | The account holder | The user, or an admin via the Admin console |
| Password policy | Google's default guidance | Admin-enforced policy and 2SV requirements |
| Recovery | Recovery email/phone | Admin reset plus recovery options |
Step 1: Audit What the Login Owns Before You Rotate Anything
Recovery options alone do not protect a login that owns ad accounts, reporting properties and tag containers.
- Billing ownership for Google ad accounts
- Admin-level access on GA4 properties and data streams
- GTM container publish rights
- Merchant Center account ownership
- Any CRM or reporting connector using the login
The Google Account Password Change Procedure, in the Correct Sequence
Run the six steps in order: audit → change → manage sessions → review third-party access → verify tooling → record.
[ ] Audit what the login owns (Ads, GA4, GTM, Merchant Center, CRM)
[ ] Document it before any change
[ ] Change the password
[ ] Sign out of all devices / review active sessions
[ ] Review third-party access at myaccount.google.com/connections
[ ] Verify Ads, GA4 and GTM still work
[ ] Record the rotation date and ownerStep 2: Change the Password Itself
Follow Google's official route: visit the account security page, choose the password option, and re-authenticate to confirm. Use a unique, long password stored in a shared password manager, not a spreadsheet. If this is a Workspace identity, confirm whether your admin's password policy applies before you choose the format.
Step 3: Sign Out of All Devices and Review Active Sessions
The password change alone does not end old sessions. Google provides a dedicated control for reviewing devices where you're signed in and, where offered, signing out of all sessions. Resolving this step is what actually defeats a stale session on a former employee's phone.
For Workspace tenants, admins can use the Admin console to sign users out and manage sessions. Consumer accounts rely on the individual account security controls.
Step 4: Review Third-Party App Access at myaccount.google.com/connections
This is the step teams skip most. Every connector your login has ever authorised appears here. Ask two questions of each entry: does this app still serve a live reporting or automation function, and does anyone own it? Anything unexplained comes out.
Removing an OAuth token can break a reporting connector silently. Expect that integrations may need reauthorisation after you revoke access.
Step 5: Verify Revenue-Critical Tooling Still Works After Rotation
Prove each connection works; don't assume. For example, a hypothetical paused campaign during a misconfigured rotation could cost a brand a day of spend - say R8,000 to R15,000 - before anyone notices. Keep this short verification checklist:
| Surface | What to confirm | Owner |
|---|---|---|
| Google Ads | Login works, campaigns running, billing card intact | Paid lead |
| GA4 | Data still flowing, admin access intact | Analytics lead |
| GTM | Container publishing, tags firing | Tracking lead |
Step 6: Record the Rotation and Stop Rotating Shared Logins
Log the date, the person who performed the change, what was revoked, and what needed reauthorisation. Then close the cause: shared logins are the root problem. Give individuals their own login and grant access through proper delegation rather than passing one password around.
Turning Credential Rotation into a POPIA-Aligned Safeguard
South Africa's Protection of Personal Information Act requires reasonable security safeguards for personal information. A disciplined rotation, documented ownership and reviewed third-party access are sensible measures supporting that expectation, not a mandated procedure. Frame it that way internally to keep claims accurate.
The Outcomes Worth Measuring: Fewer Lockouts, Cleaner Attribution
A well-run rotation produces measurable results: fewer access-related incidents, complete records of who owns what, and reporting pipelines that survive staff turnover. If a rotation does break a GTM or CRM connection, reporting integrity suffers. Prebo Digital's custom reporting approach and conversion tracking work depend on clean, connected data. Learn more via strategy consulting.
