Information Security Policy

This policy states how PXLPOD Media LLC protects the information held in Cashflow HUD, an internal financial reporting application, and in the systems that feed it.

It covers the application at cash.pxlpod.co, its database, its source repository, the hosting platform it runs on, the third-party systems it reads from, and the single workstation used to administer all of them.

It does not cover the public website at pxlpod.co, client WordPress installations, or any system operated on behalf of a client. Those are separate environments with separate controls.

PXLPOD Media LLC has two owners and one operator. Christopher Foley is the managing partner: the sole administrator of every system named here, and the accountable party for this policy. The remaining interest is held by a silent minority shareholder with no operational role, who does not use these systems and holds no account on any of them. There are no employees and no contractors.

The minority shareholder holds the credential to the administration workstation solely as a continuity measure, so the business can be recovered on the death or incapacity of the managing partner. This is deliberate and is recorded rather than omitted: a two-person company with one operator and no succession path is one accident away from losing access to its own finances, and a control that exists only in someone’s head is not a control.

This is stated plainly rather than dressed up as a security function, because a policy that invents a committee is a policy nobody follows. The practical consequence is that every control below is either automated or it is a habit — there is no second person to catch a lapse, so controls that depend on vigilance are avoided in favour of controls enforced by a system.

No payment card numbers, card security codes, or client bank account numbers are held in any classification. Payment pages are operated by Stripe; card data is transmitted directly to Stripe and does not traverse our systems.

Governed by the Access Control Policy. In summary: one operational identity, multi-factor authentication on every system, credentials scoped to the minimum required, no shared account for anything that touches confidential data, and a named continuity holder who uses none of it.

• In transit — TLS on every connection. The application is served over HTTPS only; all third-party APIs are HTTPS.
• At rest — provided by the managed database platform. The administration workstation uses full-disk encryption.
• Secrets are held in the hosting platform’s encrypted environment store and in a local environment file excluded from source control. No secret is committed to the repository.

• Row-level security is enabled on every table with no permissive policies defined. The database is therefore deny-all to any client-side key; reads and writes occur only through the application’s server-side service credential. This is verified after every migration.
• Single-owner authentication. The application has no roles, no team accounts, and no invitation mechanism.
• Read-only credentials to source systems. The Stripe key is restricted; the CRM token is read-only. Neither permits writing to a source system, so a compromise of this application cannot alter billing or CRM data.
• Migrations are additive and idempotent, one file per version, reviewed before they run.
• Deployment is by version-control push only, never from a local command line. A pre-push hook runs the production build and the projection fixtures; a failing build cannot be pushed.

Governed by the Software Lifecycle and End-of-Life Policy and the Vulnerability Remediation SLA.

Every synchronisation run is recorded with its source, trigger, timings, row counts and any errors. Failures are surfaced on the application’s health page rather than left in a platform log, on the principle that a failure which exists only in a log does not exist.

The hosting platform retains runtime logs and the database platform retains audit logs. Neither is relied upon as the primary signal.

Given a single operator, the response procedure is deliberately short.

• Contain — revoke the affected credential first. Every credential can be rotated from its own dashboard without redeploying the application.
• Assess — determine what the credential could reach. The scoping in §7 bounds this: a leaked payment-processor or CRM token is read-only; a leaked database service key reaches the ledger and nothing else.
• Notify — where client personal information is involved, affected client companies are notified without undue delay and in any case within 72 hours of confirmation.
• Record — what happened, what was reached, and what changed as a result, in the repository.

The bank connection may be revoked from within Plaid at any time, which severs the application’s access immediately.

Stated in the published privacy policy for this application, §9 and §10, which is the authoritative version and is not restated here in order to avoid the two drifting apart.

Reviewed annually and whenever a system in §4 is added, removed, or materially reconfigured. The review date and any changes are recorded in the repository history.