Information Security

Most “free margin audit” tools have a price. It’s just paid in data. You type your real ticket, your real food cost, your real labor — and the next morning a sales rep emails you with the answer they generated, plus the offer they were already going to make. The tool was the funnel. Your numbers were the qualifier.

The pattern hides because nobody asks the obvious question: where do my inputs go the moment I type them? In a working browser, you can answer that question in under a minute. Open DevTools, go to the Network tab, type a number, watch what happens. A safe tool: nothing. An unsafe tool: every keystroke POSTs to a server. The mechanics are exactly that visible.

This pillar exists because operator-grade restaurant tools should be honest about their data flow, and most aren’t. The cluster doesn’t moralize. It teaches you to check.

The four tiers of restaurant data, ranked by harm if exposed

The mental model that determines what to share, where:

• Tier 1 — Public, intentional. Hours, address, menu, cuisine type, photos. You want this on every directory you can find. No restraint needed.
• Tier 2 — Operating numbers, sensitive but bounded. Revenue ranges, average ticket, prime cost, food-cost percentage. Useful in benchmarks and comparisons. Should leave your head only when a contract names what the recipient does with it. RAMW surveys, the studio’s research notes, your accountant. Not a free margin tool from a vendor you’ve never heard of.
• Tier 3 — Customer data. Reservation lists, email addresses, the complaint log, the regular who left a one-star. Subject to privacy law (GDPR, CCPA, Maryland PIPA). Lives only in your POS, your reservations platform, and your encrypted backups. Never typed into a free tool.
• Tier 4 — Identity-bearing. EIN, owner SSN, bank routing, payment-processor credentials, vendor invoices with payment terms. The list of things that, if exposed, take six months to clean up. Lives behind 2FA, never in email, never in a shared Drive folder, never near a free tool.

The principle: data never flows up a tier. A tool that needs Tier 2 (your average ticket) to compute a Tier 1 answer (a directional industry benchmark) is suspicious. A tool that needs Tier 3 (customer emails) to compute a Tier 2 answer (a marketing list) is selling your customers. A tool that needs Tier 4 (your bank info) to compute anything other than payment processing is a scam.

The five-test audit you can run on any free tool

The full walkthrough is in How to tell if a restaurant tool is safe; the five tests, in order of how quickly they catch a bad actor:

1. The Network test (15 seconds). Open DevTools, Network tab. Type a real number into the tool. Watch the request log. If a single keystroke POSTs your input, walk away. The Muntin tools (/security/) ship a verifiable promise: zero outbound requests when you type a number.
2. The Storage test (15 seconds). Application → Storage. Type a number. Reload the page. Did your number persist? If yes — localStorage, IndexedDB, cookies — the tool is making a copy. That can be fine (the Muntin Workshop persists in localStorage by your explicit save) but it should be obvious, not surprising.
3. The View Source test (30 seconds). Right-click, View Page Source. Search for “fetch(” or “XMLHttpRequest”. A safe tool has zero hits in the calculator’s code path; an unsafe tool calls fetch() in the keystroke handler.
4. The integrity-hash test (1 minute). The site publishes /security/integrity.txt with SHA-256 hashes of every shipped JS file. You can hash the file your browser actually loaded and compare. If they match, the JS you ran is the JS the studio claims to ship. /security/integrity.txt on this site.
5. The competitor-side test (5 minutes). Run the same five tests on a comparable tool. The difference is the load-bearing argument. Most “free margin” calculators fail at least three of the five.

The vendor question

Beyond the tools themselves, the vendor question: who do you let see your data when you set up your stack? The honest answer for an independent restaurant looks something like this:

• POS (Toast, Square, Clover). Tier 3 data lives here. The contract is what matters; read the data-export clause and the data-deletion clause before you sign.
• Reservations platform (OpenTable, Resy, Tock). Tier 3 data lives here. Most platforms aggregate your data into trend reports they sell back to the industry — legally fine, but ask about it before you commit.
• Aggregators (DoorDash, Uber Eats, Grubhub). Tier 3 data lives here, with explicit non-portability. The aggregator owns the customer relationship; you own the kitchen relationship. The DoorDash math op-ed (/library/third-party-delivery-economics/) makes the case for direct-channel ownership for this reason.
• Free tools that ask for your numbers. The five-test audit applies. If they fail, type fictional numbers; if you can’t test the tool with fake numbers, that’s the answer.

Incident response: what to do if your stack is breached

The likeliest breach scenario for an independent restaurant is a POS-vendor breach (someone else’s code), not your own. The four steps in order:

1. Verify the breach is real. Phishing claims of “your data was exposed” are themselves a phish. Check the vendor’s own incident page, not the email link. Maryland PIPA gives the vendor 45 days to file with the Attorney General; the breach is real if the AG’s register has it.
2. Read what was exposed. Tier 1 (hours, address) — nothing to do. Tier 2 (revenue) — awkward but not actionable. Tier 3 (customer emails) — your guests need notification under most state laws. Tier 4 (banking, payment-processor creds) — freeze the accounts, rotate credentials, file with the FBI.
3. Notify customers if the breach is Tier 3. Maryland law (PIPA) requires notification within 45 days for residents whose data was exposed. The notification is template-able; the AG’s page has the framework. Do this even if the vendor says they’ll notify; your customers signed up with you, not the vendor.
4. Document the timeline. When you found out, what was exposed, what you did, when you notified. Maryland PIPA requires retention of this for at least three years. The studio uses a single GDocs file per incident; tabular, simple.

What to do this month

Three actions:

1. Run the five-test audit on every “free margin” tool you currently have a tab open to. Most fail. The ones that pass are the ones to keep using.
2. List your vendors by tier. Which vendor has Tier 1, 2, 3, and 4 data? Most operators have never made the list. The act of writing it down catches the over-shares.
3. Set up a free LastPass / 1Password / Bitwarden vault for the studio’s credentials. Tier 4 data should never be in a Google Sheet. Migrate this month; it takes 90 minutes one-time and saves a six-month cleanup later.

Operators who want studio-side help: the $499 audit includes a vendor-by-tier walk for the operator’s current stack as part of the deliverable.

Where this topic touches the others

• Operations & Margin — because the Tier 2 data (your operating numbers) is the input to most margin work. Protect it where it lives; don’t scatter it across free tools.
• Trust & Reviews — because the credibility frame that earns reviews from your guests is the same frame that should earn your trust from your vendors.
• AI Search & Citation — because AI search models are an emerging vendor class, and the “does it train on my data” question is a Tier 2 question. The /ai/ page documents the studio’s posture; operators evaluating AI tools should ask the same questions.

The composite to watch: your tier-by-vendor list, refreshed quarterly. The list itself is the discipline.