# Reply #2 to Tom (2026-06-05) — SENT (Mike's final, as actually sent)

**Status:** SENT 2026-06-05 by Mike. This file reflects the ACTUAL sent text (Mike strengthened the
CVV warning and the key-backup guidance vs the draft).
**Context:** Tom is rearchitecting — separate web-DB server on 0.55 (old finance box; live MAS90 now
on 0.202), scoped `web` login, stored procs, dead-page removal, deleting cc_code; he shared AES-256
cell encryption (DMK + CreditCards_Key); test build early next week, then ACG does the permissions
tighten + security pass.
**Sent with attachment:** `2026-06-05-tom-quo-checklist.txt` (the 80-site quo() list).

---

**Subject:** Re: Glaztech site

Hi Tom,

Attached is the list of pages with the in-line SQL (file + line numbers) - that's your checklist for the stored-proc conversion. Cleaning out the dead pages while you're in there is great; less surface to worry about. And thanks for clarifying the 0.55 / 0.202 piece - that actually makes 0.55 a perfect home for the website databases, and keeping the live finance data on 0.202 separate from the public site is exactly the right shape. The whole plan - dedicated web-DB server, a scoped "web" login, stored procs, synced data - is really solid.

A couple of things to flag, and a couple we can just go over together when I come in:

- On the CVV (cc_code): deleting the column is the right move. One heads-up - keeping a hand/written copy of the codes for the office runs into the same rule that made the database copy a problem: the card brands (PCI) don't allow the CVV to be retained after a sale in any form, paper included. The good news is you almost certainly don't need them - for stored/recurring cards, the processor lets the office run the payment without the CVV (it's only required at the very first authorization). So the cleanest path is to not retain them at all and process saved cards without it. Happy to confirm the exact details with your payment processor so Alex and the office folks know what to expect. In the end, I'm not the PCI police - but you will instantly be denied a cyber-insurance claim if any investigator finds that information, and you run the risk of being blacklisted by card providers in the same way. There are very few 'you must NEVER do this thing' rules in PCI compliance, and storing CVV is one of them.

- On the encryption: good - that's real AES-256. A couple of details decide how much protection it actually gives (mainly what's allowed to open the key, and how the site hands over the password to decrypt) - exactly the kind of thing I'll check when I come in to tighten the logins, nothing for you to chase now. One practical favor though: please make sure the master key, the CreditCards_Key, and the master-key password are backed up somewhere safe and separate - if that password is ever lost, the encrypted card data can't be recovered. Given the sensitivity of those items, there should be multiple controlled backups of those keys, in very secure locations. For example one should be 'in-hand' for you, and Alex at minimum. You can provide one to me and I'll vault it for you as well. (Check with Alex on that first though) Those can never be lost, so extra care in storage is important.

- On the new sync job that copies data to 0.55 through the day - when you set it up, let's have it run under a dedicated limited account rather than a full admin one, so we don't end up with broad credentials sitting in a job. I can help wire that up so it's least-privilege from the start.

Early next week for a test build sounds great. Once it's up I'll come in, tighten all the login permissions, and do a full pass for any security gaps. This is shaping up exactly the way it should.

Let me know if any questions,
Mike

---

## Open / pending follow-ups
- **Key escrow offer:** Mike offered to vault a copy of Glaztech's encryption keys + master-key
  password (after Tom checks with Alex). If accepted -> store under the SOPS vault (likely
  `clients/glaztech/...`), with controlled access. Pending Tom/Alex.
- **CVV:** Tom to delete `cc_code` AND not keep any paper copy (Alex was going to make one — corrected).
- **Encryption hardening (ACG security pass, when 0.55 test build is up ~next week):** verify which
  principal can OPEN the symmetric key (web login must NOT), where the app keeps the key password,
  and that the DMK/key/password are backed up.
- **Intraday sync job (live -> 0.55):** must run under a dedicated least-priv account.
- **Permissions tighten + full security gap review:** ACG, once Tom's test build is operational.
