Information Security Policy

Organization: Bradley Mayer, operating Mayer Money Owner: Brad Mayer Effective: 2026-11-10 · Next review: 2027-11-10, or sooner after any security incident or major change

This policy is published. It describes systems by what they do, not by their internal names or addresses; those are kept in the private setup notes.

1. Purpose and scope

Mayer Money is a private, self-hosted budgeting app used by one household (Brad and Ashleigh Mayer). It reads transaction and balance data from the household's own bank accounts, through Plaid and through CSV files the household downloads itself. It has no outside customers, sells nothing, and shares data with no one.

This policy covers:

• The Mayer Money application and its source code, kept in a private code repository.
• The home server that runs the app in a container, and the storage on it that holds the app's data.
• The admin accounts used to run it: the home server's administrator accounts, the code repository, the Plaid Dashboard and the private remote-access network.
• The owner's computer when it is used to develop the app or read the app's data.

Consumer financial data here means any transaction, balance, account name or bank connection token, whether it came from Plaid or from a bank CSV.

2. Roles

Access rules are in the Access Control Policy.

3. How the system is protected

Network. The app is not exposed to the internet. No router ports are forwarded to it. Remote access goes only through a private, identity-based network (Tailscale): a device must be signed in to the owner's account before it can reach the app. Remote connections use HTTPS with a publicly trusted certificate. The home network's gateway filters DNS.

Every request is checked. Being on the home network or the private network is not enough. Every page and API call, except a health check that returns only the code version and the app's static code files, requires a signed-in session. Every request that changes data must also come from the app's own origin.

Sign-in. Named accounts only, no shared logins. Every sign-in needs a password and a six-digit code from an authenticator app (Microsoft Authenticator, Google Authenticator or similar). There's no way to skip the code: someone who hasn't set up an app is shown a QR code and can't get in until they do. Passwords are at least 8 characters and stored only as salted scrypt hashes. A code works once. Five wrong passwords or codes lock a name for 15 minutes; 20 from one address lock that address. Sessions are signed, HttpOnly, SameSite=Lax cookies that last 30 days. Changing or resetting a password signs that person out everywhere else.

Roles. Each account is Admin or Read only, checked by the server on every request. See the Access Control Policy.

Tokens and keys.

• Plaid access tokens are encrypted at rest (Fernet: AES-128 with an HMAC integrity check). The encryption key is stored apart from the app's data, so backups of the data never carry a working token.
• The Plaid client ID and secret live only in the app's settings file on the home server.
• The key that signs sign-in cookies is 32 random bytes, created on first start.
• The home server pulls code from the repository with a read-only key.
• None of these are ever stored in the code repository, which is set up to refuse key, settings, database and CSV files.
• Plaid tokens and sign-in accounts are never included in data exports.

File permissions. On every start the app resets its data, settings and key files so only the home server's administrators can read them, and new files are never readable by other accounts.

Bank sign-in. Banks that support it use their own sign-in page through Plaid (OAuth). Mayer Money and Plaid never see the bank password. The Plaid connection is read-only (Transactions product): it cannot move money.

Audit trail. Every budget edit is kept with who made it and when. Account changes record who created or last changed each sign-in.

Backups. The app copies its database and data files daily and keeps 30 days. Retention and deletion rules are in the Data Retention and Deletion Policy.

4. Multi-factor authentication

MFA is required on every account that can reach consumer financial data or change the system:

5. Vulnerability management

Scanning. These run on a schedule:

Patching deadlines (SLA). From the day a fix is available:

If a fix can't be applied in time, the owner writes down why and what reduces the risk meanwhile (for example, turning off the affected feature or removing a bank connection) in the log below.

How updates ship. Code changes are tested on a copy of the data on the owner's computer, then published to the repository; the home server picks them up within 5 minutes. Package versions are pinned, so every update is a reviewed change.

Vulnerability log. Findings, what was done, and any exception to the deadlines above.

6. Development rules

• No financial data in the repository, ever. Test data stays outside it.
• Never edit the live data or the server's copy of the code directly.
• Changes to categorization or balance math are shown with before/after numbers before they ship.
• Secrets are never pasted into chat tools, tickets or commit messages.

7. Incidents

A security incident is anything that may have exposed financial data or a credential: a lost phone or laptop that was signed in, an unknown device on the private network, an unknown sign-in, a leaked key, or a breach notice from Plaid or any provider listed in section 4.

1. Contain (same day): remove the device from the private network; reset the affected Mayer Money passwords (this signs that person out everywhere); rotate whatever key leaked (Plaid secret in the Plaid Dashboard, the repository's read-only key, the cookie-signing key, or the bank-token key by disconnecting and reconnecting the bank).
2. Assess: check the app's edit history, its logs, and the private network's device and sign-in logs.
3. Notify: if Plaid-sourced data may have been exposed, tell Plaid (security@plaid.com) and the affected household members promptly, and within 72 hours at most.
4. Record what happened and what changed in the log below.

8. Policy review

Reviewed once a year, after any incident, and when the system changes in a way this document doesn't describe.