VIDEO · COMING SOON 4-minute screencast of the full Audit Retainer onboarding flow. Recorded once first Audit subscriber lands; until then, the full text walkthrough below covers the same flow.

Day 0 — Stripe checkout + intake call scheduling

DAY 0 · STRIPE PAYMENT

You complete checkout

From the Audit Retainer page you click "Start Audit Scale — $9,999/mo" (or Pro / Enterprise). Stripe handles payment. garnetgrid-fulfillment creates an envelope at garnet-tokens/audit/<slug>.json and sends a welcome email via Postal.

Sample welcome email body

Subject: Welcome to Audit Scale — your kickoff call Hi [your name], Audit Scale is active. Reply with 2-3 windows in the next 5 business days and we'll lock the 60-min intake call. Your dashboard: https://www.garnetgrid.com/account/audit/[16-char-slug] What we'll cover on the intake call: · Audit scope (which repos, which clouds, which compliance frameworks) · Read-only credential provisioning (we only need OBSERVE, never WRITE) · Tracker integration (Linear / Jira / GitHub Issues) · Communication channel — Discord by default, your channel of choice Snapshot writer Worker deploys within 24 hours of the intake call. First daily snapshot lands the next morning. — Jakub Rezayev, Garnet Grid Consulting

Day 1–2 — Intake call

DAY 1-2 · 60-MINUTE INTAKE

Scope, credentials, tracker integration

The intake call is the engineer who ships the work talking to your CTO / Staff Engineer / Platform Lead. Three deliverables come out of it:

Scope document — repos in scope, cloud accounts in scope, compliance frameworks (SOC 2 / ISO 27001 / HIPAA / GDPR), exclusions (e.g. "skip the legacy /v1 API; we're sunsetting it Q3").
Credential plan — which read-only credentials need provisioning. AWS IAM role with SecurityAudit + a custom policy for cost-bill API; GCP service account with roles/viewer + billing reader; Azure Reader role at the subscription scope; observability platform read tokens (Datadog API, CloudWatch, Grafana, Sentry).
Tracker integration plan — Garnet engineer onboards into your Linear / Jira / GitHub Issues. Tickets land in a designated team/project labeled garnet-audit, scoped + sized + assigned to Garnet.

DAY 1-2 · INFRASTRUCTURE PROVISIONING

Snapshot writer Worker deploys

Garnet engineer deploys the audit snapshot writer Worker into your Cloudflare account, configured with the read-only credentials provisioned in the intake call.

Worker name: garnet-audit-snapshot-writer
Cron trigger: 0 3 * * * (03:00 UTC daily)
R2 bindings: garnet-snapshots, garnet-tokens
Secrets: AWS / GCP / Azure read keys, Datadog API key, GitHub PAT (for repo scans)

First nightly run completes within 24 hours. Snapshots land at garnet-snapshots/audit/<slug>/<YYYY-MM-DD>/<source>.json.

Day 3 — First daily snapshot

DAY 3 · BASELINE SNAPSHOT

The four-axis baseline lands in your R2

Snapshots cover all four axes. Each axis is one source file:

Sample architecture snapshot record

{ "date": "2026-05-12", "axis": "architecture", "schema_fingerprints": { "postgres-primary": "sha256:8c3d92...", "tf-state-prod": "sha256:a17f00...", "openapi-public": "sha256:5290be..." }, "service_topology": { "services": 14, "edges": 32, "blast_radius_groups": [ { "service": "auth-svc", "depends_on_count": 0, "dependents": 11 }, { "service": "billing-svc", "depends_on_count": 3, "dependents": 4 } ] }, "iam_graph_hash": "sha256:0e2a1d...", "iac_repos_audited": ["org/infra-prod", "org/k8s-manifests"] }

Day 7 — First weekly drift diff

DAY 7 · WEEKLY DRIFT REPORT

Engineer sits with the diff, opens the first round of tickets

The Garnet engineer reviews the week's snapshots, computes the diff (architecture / security / cost / latency), and ships three artifacts:

Drift report — what changed, severity-graded, estimated time-to-fix per item. Lands in #audit-drift Discord channel.
Engineering tickets — for Scale + Enterprise tiers, every red/amber finding becomes a ticket in your tracker, scoped + sized + assigned to Garnet.
Pre-mortem entries — for any finding involving a non-trivial architecture change, a 1-page pre-mortem authored before any work starts.

Sample week-1 drift report excerpt

Week 1 drift report · 2026-05-19 Architecture (3 findings) R · auth-svc has 11 dependents, no failover routing — single point of failure. Garnet ticket GAR-201, est 8h. A · openapi-public spec drifted (5 endpoints renamed since 2026-04-30) — public clients on old paths get 404. GAR-202, est 4h. G · k8s-manifests now using affinity rules (good, post-incident learning). Security (2 findings) R · 3 IAM roles haven't rotated keys in >90d (above 60d policy ceiling). GAR-203, est 2h. A · 1 Datadog API key found in repo history (not currently active in head, but exposed in git history). GAR-204, est 1h to rotate. Cost (1 finding) A · Lambda spend up 28% week-over-week (deploy 2026-05-15 introduced a synchronous fan-out). GAR-205, est 6h to refactor. Latency (clean — no regressions vs prior week baseline)

Day 14 — First merged ticket

DAY 14 · FIRST MERGED PR

Engineering follow-through

Tickets opened on Day 7 are picked up by Garnet engineer. By Day 14 the first PR typically lands in your repo: a real code change addressing one of the red findings.

Sample PR description

title: fix(auth): rotate stale IAM keys + enforce 60-day rotation policy Closes GAR-203 from week-1 drift report. Three IAM roles had keys older than 60 days (current policy ceiling). This PR: 1. Rotates the 3 stale keys via aws-vault rotate (new keys committed to AWS Secrets Manager, old keys disabled with 24-hour grace period). 2. Adds a CloudWatch alarm: fires when any tracked role's key age exceeds 50d (10-day pre-emptive warning). 3. Adds a Terraform check (tfsec custom rule) blocking PRs that introduce a role without a rotation tag. Test plan: alarm fires in staging when test role's key is artificially aged. PR comments include the alarm screenshot. Authored: Garnet engineer (post-week-1 audit drift report).

Day 30 — First executive PDF

DAY 30 · MONTHLY DELIVERY

The audit-monthly Workflow renders + emails the PDF

On the 1st of next month, garnet-audit-monthly Workflow fires for your slug. The 14-step pipeline rolls up the month's findings, ships shipped tickets list, computes posture deltas, renders PDF via Cloudflare Browser Rendering, stores at garnet-reports/audit/<slug>/<YYYY-MM>.pdf, and emails it to your billing address.

The PDF covers:

Findings dashboard (opened / closed / carried, severity-grouped, with closure rate)
Engineering tickets shipped (repo, PR number, 1-line summary, before/after metric)
Architecture schema diff (what's new in the topology, with rationale + blast-radius diagrams)
Compliance posture (SOC 2 / ISO / HIPAA / GDPR % progress, gap-list, next-90-day projection)
Cost + latency posture (cloud spend Δ, LLM spend Δ, p95 Δ vs. last month, anomaly attributions)
3–5 prioritized next-cycle recommendations
Pre-mortems shipped (which changes were authored, whether they caught something pre-merge)

Steady-state cadence from here: daily snapshots, weekly drift report + tickets, monthly executive PDF. The same engineer ships every cycle.

What you DON'T see in this walkthrough

No Big-4 partner intro deck — the engineer who scoped the audit is the engineer running it. Skip the rotating-associates ceremony.
No 30-page slide-deck deliverable on Day 30 — the PDF is structured around shipped engineering work, not a recommendation list. Findings stay open in your tracker until merged.
No SaaS dashboard owning your audit data — snapshots live in your R2. Diff control plane is encrypted and tenant-only. Cancellation removes Garnet's read access; your data stays.

See Audit Retainer pricing → Read the methodology → Compare vs alternatives →

Audit Retainer onboarding — Day 0 to Day 30.