Part 14 — Existing & live projects: retrofit track and keeping every blueprint current

Most real projects already have code, and many already have users. This track turns what’s built into a complete blueprint, closes the riskiest gaps first, and keeps every project’s blueprint current from then on.

14.1 Pick the track

Your project is…	Track	Start with
An idea, or a prototype that has never held real people’s data	New project	Part 0, then gates G0–G4
Built, but used only by you or testers with synthetic data	Retrofit, light	14.3 → 14.4. Pass G2 before any real data.
Live with real users, customers or a client	Retrofit, urgent	14.2 Day-0 triage within 48 hours, then 14.3 → 14.4 → 14.5
Inherited, built by someone else, or generated by an AI tool you don’t fully understand	Retrofit, urgent	As for live projects, plus a line-by-line review of every auth and data-access path

Retrofit gates:

R0 Triage done.
R1 Critical gaps closed.
R2 Blueprint complete: the as-is state documented and every gap registered.

After R2, all new scope follows the normal Definition of Done (11.2) and gates.

14.2 Day-0 triage for live projects (first 48 hours)

#	Check	How to check	If it fails
T1	Exposed secrets	Scan the git history (gitleaks), the built client bundle and any mobile binaries for secret or service keys. Check public-prefixed variables (`NEXT_PUBLIC_`, `VITE_`, `EXPO_PUBLIC_`).	Rotate immediately, purge from history and review access logs (9.20)
T2	Database access rules	Supabase: run the query below and review every policy (5.4). Firebase: confirm Security Rules aren’t test-mode rules (`allow read, write: if true`) and test them with the emulator. MySQL or another database without RLS: confirm every query runs through a tenant scope and an authorisation policy, and test it (5.4).	Lock down today; assess exposure (T12)
T3	Storage buckets	List the buckets and confirm user uploads are private and served through signed URLs	Make them private; invalidate public links
T4	Third-party requests before consent	Run the 9.9 Playwright test against the live site (`use.baseURL` = production URL; `ALLOWED_HOSTS` = your domains)	Remove or consent-gate fonts, CDNs and pixels this week
T5	Tracking & replay	Inventory analytics, replay, pixels and A/B tools	Switch off anything non-essential until consent gating ships; delete recordings collected without consent
T6	Marketing email	Inspect the last campaign: unsubscribe link, `List-Unsubscribe` headers, sender identity, address. Check that each list has consent evidence.	Pause sends; fix the template; suppress contacts with no evidence
T7	Privacy notice	It exists, is linked from the footer and sign-up, and matches what the app actually does	Publish an accurate interim notice now; the full one follows 14.3
T8	Children	Could under-18s be using it (students, learner drivers, families, pupils)?	Decide the position (9.12); add an age check at next sign-in if needed
T9	Sensitive data	Health, location, religion, biometrics or other C3 data present? Is there a DPIA?	Start the DPIA (9.21); restrict access; stop sending it to AI or analytics
T10	Registration & contracts	ICO fee paid; DPAs with processors; a DPA with your client if you’re their processor (9.2)	Pay and sign this week
T11	Credentials agents and CI can reach	List every token and key the agent’s machine or container, its MCP server configs and CI can reach, with each one’s scope: `.env*` files, `~/.npmrc`, `~/.aws/credentials`, CLI logins for your host and database, API keys in MCP configs (such as `.mcp.json`), and CI secrets	Replace production and account-wide tokens with scoped, short-lived ones where the provider offers them; otherwise remove them from that machine and from CI jobs that run untrusted code. Move production changes into CI/CD with approval (12.1)
T12	Was anything exposed?	If T1–T3 or T11 failed, check access logs for unauthorised access	Treat it as a potential breach (9.20). The 72-hour clock runs from when you become aware a breach has occurred.

Find tables without RLS (Supabase SQL editor):

select c.relname as table_without_rls
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind in ('r', 'p') and not c.relrowsecurity
order by 1;

Retrofit legal realities

Past processing can’t be made lawful after the fact. Stop it, delete what you shouldn’t hold, and do it right from now on.

Don’t email people to ask for marketing consent if you didn’t already have consent to email them. The ICO treats “re-permission” emails as marketing in themselves; in 2017 it fined Flybe £70,000 and Honda £13,000 for exactly this. Ask in-product instead, e.g. at the next sign-in.

Tell existing users about material changes to the privacy notice. Request new consents in-product; never infer them from silence.

14.3 Reverse-engineer the blueprint from what’s built

Work from evidence, not memory. Record the as-is state in each section, and log every difference from the blueprint standard as a GAP (14.4).

Blueprint part	Evidence	How
Part 0 intake	Who uses it, where they are, which data types	Aggregate analytics, the database, the support inbox
3.1 stack · 3.6 processors	Dependencies, environment variables, hosting and SaaS accounts	`package.json` / `pubspec.yaml` and lockfiles. Billing statements are the honest vendor list.
3.6 · 9.8 · 9.9 browser and device traffic	Every domain contacted; every cookie and storage key; mobile SDKs	DevTools Network and Application tabs in a fresh profile; the 9.9 test; a proxy or network inspector for mobile
5.2 data dictionary	Every table, collection and field	`prisma db pull`, `supabase db dump`, a Firestore export
5.4 access rules	Policies or rules per table	`select * from pg_policies;`, the Firebase rules file, the query above
6.2 API inventory	Routes, Server Actions, cloud functions, webhooks	Code search; framework route listing
9.3 RoPA	What each data set is for and who receives it	All of the above, plus email, AI and analytics settings
10.3 screens · 10.7 state matrix	Every screen, and which states it handles	Click through with throttling, offline mode, an expired session and a low-privilege account
7.3 threats	Auth flows, uploads, rendering of user content, AI prompts	Code review of every auth and data path
Part 4 ADRs	Key past decisions	Write them retroactively with “Status: Accepted (retroactive)”

14.4 Gap register & remediation plan

GAP	Area	Finding (as-is)	Standard (ref)	Risk	Severity	Fix	Owner	Due	Status
GAP-01	{{Privacy}}	{{Google Fonts loaded from Google on every page}}	9.9	{{Legal}}	{{Critical}}	{{Switch to next/font}}	{{ }}	{{ }}	Open

Severity → deadline:

Critical: live exposure of personal data or secrets; tracking or marketing without a lawful basis; children’s or special category data without safeguards. Fix within days (R1).
High: missing rights features or DPAs; an inaccurate privacy notice; no access-isolation (RLS) tests; no breach plan. Fix within 2–4 weeks.
Medium: missing UI states on key journeys, accessibility failures, incomplete retention jobs. Fix within 1–2 months.
Low: documentation and polish. Backlog.

Remediation sprints:

Sprint	Focus
R1 (week 1)	Day-0 failures fixed; interim privacy notice; consent gating; unsubscribe and suppression; secrets rotated
R2 (weeks 2–4)	RoPA, processor register and DPAs, privacy centre (export and delete), retention jobs, breach runbook, complaints route, DPIA for the High tier
R3 (weeks 4–8)	RLS, privacy and E2E tests in CI; state-matrix gaps on the top journeys; accessibility fixes; security headers and CSP
R4 (ongoing)	Remaining gaps through normal delivery; launch-trap audit (9.26) every quarter

14.5 Keep every blueprint current (new and existing projects)

The blueprint lives in the repo (docs/BLUEPRINT.md) and changes in the same PR as the code (Definition of Done, 11.2).

When you…	Update
Add or change a feature	FR and acceptance criteria (1.5–1.6), screens and state matrix (10.3, 10.7), API (6.2), tests
Add a data field or table	Data dictionary (5.2), RoPA (9.3), privacy notice (9.6), access rule (RLS where supported) and its isolation test (5.4), retention (5.6)
Add a vendor, SDK, script, font or embed	Processor register (3.6), cookie register (9.8), CSP (7.4), DPA (9.18), consent loader
Launch in a new country	Laws (9.1), registrations (9.2), transfers (9.17), notice
Serve a new group (children, patients, workers)	Re-run the Part 0 screening; DPIA (9.21)
Add or change AI	Part 8, evals, notice wording
Change the stack or a key decision	A new ADR (Part 4)
Have an incident	Post-incident review (A7), threat model (7.3), runbooks

Cadence for live projects:

Monthly 15-minute review: open gaps, new vendors, calendar items.
Quarterly: launch-trap audit (9.26) and cookie scan.
Annually: full review, plus a framework-version check.

Framework versioning: each project blueprint records Framework: Bansat v2.4. When this master framework changes (a law, a guideline, a better pattern), its revision history lists what to re-check. Apply that list to each project at its next monthly review.

14.6 Portfolio register

If you run several projects, keep one row per project and review it monthly.

Project	Stage (idea / build / beta / live)	Users & markets	Risk tier	Track	Blueprint (none / partial / complete)	Day-0 triage	Open critical gaps	Next review
{{ }}