Privileged Access Management Policy

Controls for managing and securing privileged access to Wealthy’s systems.

Privileged Access Management

Field Value
Document ID POL-018
Classification Internal
Owner CTO (interim CISO)
Effective Date April 2026
Review Cycle Annual

How we manage admin-level access across Wealthy’s systems. Only the right people, only when needed, everything tracked.

Scope

Applies to elevated access on: GCP, AWS, Kubernetes, Cloud SQL, GitHub, Pritunl VPN, Cloudflare, CloudFront, Kong, Google Workspace Admin, internal tools (Pulse, Garage, Starlink), and secrets management.

How Access Works

Almost all access at Wealthy is tied to Google Workspace SSO. This means:

  • Internal tools, GCP, VPN (Pritunl), admin panels — all authenticate via Google SSO
  • When someone leaves the org → Google email is disabled → access to all SSO-linked systems is automatically revoked
  • No separate credentials to chase for most systems

For the few systems not on SSO (AWS IAM, standalone service credentials):

Requirement Standard
Minimum Length Strong password with complexity
Rotation Periodic (as per organization policy)
MFA Mandatory

Session Rules

Rule Standard
Session Expiration Sessions expire after a defined period — mandatory re-login
Idle Timeout Auto-logout after a period of inactivity
Screensaver Lock Idle lock enabled, password-protected

Account Tiers

Tier 1 — Critical

GCP/AWS root, Cloud SQL admin, GKE cluster-admin, Secrets Manager admin, Google Workspace Super Admin.

→ Restricted to minimum required personnel. CTO approval. Periodic review.

Tier 2 — High Risk

CI/CD admin, Pritunl admin, Cloudflare/CloudFront admin, Kong admin, Grafana admin.

→ Team lead + CTO approval. Periodic review.

Tier 3 — Elevated

GitHub write access, internal tool admin, staging environment admin, DNS management.

→ Team lead approval. Periodic review.

Requesting Access

All access goes through Plane:

  1. Create a Plane ticket — specify system, access level, and why you need it
  2. Tag the DevOps person on the ticket
  3. Share the ticket in #access-approval
  4. CTO approves on the ticket
  5. DevOps provisions and updates the ticket

Rules:

  • No access without a Plane ticket — Slack/verbal requests don’t count
  • Role-based access where possible (GCP IAM roles, GitHub teams, Pritunl groups)
  • No shared credentials — each person has their own identity
  • No standing prod database access — time-bound only
  • No credentials in code — use Secrets Manager

Access Revocation

When Someone Leaves

Google email disabled = access revoked for all SSO-linked systems. That covers the majority of access.

For the remaining non-SSO systems:

  • AWS IAM access removed
  • GitHub org membership removed
  • SSH keys rotated on servers they accessed
  • Any standalone credentials rotated

Timeline: As soon as possible after exit. HR notifies → DevOps executes.

Other Triggers

Trigger Timeline
Role change Promptly
Project completion Promptly
Security incident Immediately (DevOps/CTO)

Service Accounts

  • Every service account has a designated human owner
  • Credentials rotated periodically
  • Least privilege — minimum required permissions only
  • Periodic review of all service accounts
  • Disabled immediately when no longer needed

Access Reviews

Scope Frequency Reviewer
Tier 1 (Critical) Periodic CTO
Tier 2 (High Risk) Periodic Engineering Manager
Tier 3 (Elevated) Periodic Team Leads
Service accounts Periodic System owners
Dormant accounts Periodic DevOps/CTO

Break-Glass (Emergency Access)

For P0/P1 incidents when normal approval isn’t available:

  • Emergency credentials maintained by CTO
  • All usage fully logged
  • Post-incident review mandatory
  • Credentials rotated after every use

Monitoring & Logging

What’s Logged

Activity Log Source
Login attempts (success + failure) Google Workspace audit logs
Cloud resource access & changes GCP Cloud Audit Logs, AWS CloudTrail
VPN connections & disconnections Pritunl server logs
Database queries on production Cloud SQL audit logs, slow query logs
Code deployments GitHub Actions logs, CI/CD pipeline logs
Permission & IAM changes GCP IAM audit logs, AWS IAM events
Admin panel access Application-level access logs

Alerts

Alert Trigger Notified
Brute force attempt Repeated failed login attempts DevOps
Privilege escalation IAM role/permission change DevOps/CTO
Unusual login location Login from a new country/IP DevOps
Break-glass usage Emergency credential used CTO
Off-hours access Privileged action outside business hours DevOps
Service account anomaly Unusual API call pattern or volume DevOps
Root account login AWS root or GCP org-admin login CTO

Log Retention

  • All access and audit logs retained as per organization’s retention policy
  • Logs stored in centralized logging (GCP Cloud Logging)
  • Log access restricted to DevOps/CTO — no self-service deletion