Information Security Policy

Scope. This policy covers the PhurFriend application, its production database and file storage, the third-party services it depends on, and every device used to develop or operate it. It applies to all personnel with access to production systems.

Owner. PhurFriend is operated by a single owner-operator, who is accountable for every control described here. Reviewed at least annually, and on any material change to the architecture or to the personnel with production access.

1. Governance and risk

Security decisions are the owner's responsibility and are not delegated. The principal risks to this business are identified as: unauthorised access to one customer's books by another customer, compromise of the credentials that reach our infrastructure providers, exposure of bank access tokens, and loss of customer data. Each control below exists against one of those risks rather than against a checklist.

This policy is reviewed annually. Any security incident triggers an immediate review of the controls in the affected area.

2. Asset and data inventory

Customer data is held in one place: a managed PostgreSQL database and its associated file storage, both operated by Supabase. Application code runs on Vercel. No customer data is stored on local machines, on removable media, or in any spreadsheet or note outside those systems.

The data we hold is:

• Account identity — name, email address, company name.
• Financial records the customer creates or imports — jobs, budgets, contracts, transactions, invoices, payroll rates, receipt images.
• Bank access tokens issued by Plaid, which permit reading transactions only.

We do not hold bank credentials, full payment card numbers, or Social Security numbers. Payment card details are handled entirely by Stripe and never reach our systems.

3. Access control

Authorisation is enforced in the database, not in application code. Every table containing customer data has PostgreSQL row-level security enabled, keyed to the company of the signed-in user. A query cannot return another company's rows even if the application layer contains a bug.

Within a company, roles are enforced by the same mechanism. An accountant granted read-only access can see everything and change nothing, and that restriction is a database policy rather than a hidden button.

Plaid access tokens are held to a stricter rule: no browser session may read them under any role. They are readable only by server-side code using a service credential that is never sent to a client.

Access to production infrastructure is limited to the owner. Access is granted on the principle of least privilege, and reviewed whenever anyone joins or leaves.

4. Authentication

Customer accounts support time-based one-time password (TOTP) two-factor authentication and Google single sign-on. Passwords are hashed by Supabase Auth and are never stored or transmitted in recoverable form.

Two-factor authentication is optional for general use of the product but mandatory before a bank account can be connected. A session that has not cleared a second factor cannot obtain a Plaid link token or exchange one, and the refusal is enforced server-side on both endpoints. Bank connection is additionally restricted to the account owner; staff and read-only members cannot initiate or remove one. Our TOTP implementation is not phishing-resistant in the WebAuthn sense; passkey support is planned.

Password reset links expire one hour after issue. Authentication endpoints and password reset requests are rate limited independently of one another.

All administrative accounts with production access — hosting, database, source control, payment and banking providers — have two-factor authentication enabled.

5. Encryption

Data in transit is protected by TLS 1.2 or higher on all connections. There is no plaintext HTTP path to the application. Data at rest, including database contents, file storage and backups, is encrypted with AES-256 by our infrastructure providers.

6. Secrets management

All API keys, database credentials and service tokens are held as environment variables managed by the hosting platform. Secrets are never committed to source control; environment files are excluded from version control and have never been committed. Secrets are rotated on any suspicion of exposure and whenever anyone with access to them departs.

7. Change control and secure development

All changes are tracked in version control with a complete history. Before any deployment, an automated suite runs static type checking, linting and the full test suite; deployment proceeds automatically from the main branch only when these pass.

Because the company is currently a single operator, changes are not reviewed by a second person. This is a known limitation. Automated testing is treated as the compensating control, and peer review will be introduced as soon as a second engineer has production access.

8. Vulnerability management

Dependencies are audited for known vulnerabilities as part of the development cycle and automated dependency alerts are enabled on the source repository. Vulnerabilities are remediated on the following timeline from the point at which we become aware of them:

• Critical — within 7 days.
• High — within 30 days.
• Medium and low — within 90 days.

Operating system, runtime and database patching is performed by Vercel and Supabase as managed services.

9. Application security controls

Rate limiting is applied per endpoint to authentication, password reset, data import, AI processing, exports and general writes. Uploaded files are restricted to an explicit list of permitted types. Prices are set server-side and cannot be altered by a client. Session cookies are issued with secure attributes by the authentication provider.

Text that originates outside our systems — including transaction descriptions from a bank — is treated as untrusted and neutralised before it is passed to any language model. Structural validation is applied independently: a job or category returned by a model is rejected unless it matches a record the customer actually owns.

10. Logging and monitoring

Security-relevant events are written as structured logs and retained by the hosting platform, where they are searchable. Logged events include permission denials, rate limit breaches and suspected prompt-injection attempts. Authentication events, including failed sign-in attempts, are logged by Supabase Auth.

Logs are written so that they cannot contain passwords, tokens or full financial descriptions. Email addresses appearing in security logs are masked.

11. Incident response

On discovering a suspected incident the owner will, in order:

1. Contain. Revoke affected credentials, disable affected access, and where necessary take the application offline in preference to allowing continued exposure.
2. Assess. Determine what data was reachable, by whom, and for how long, using platform and application logs.
3. Notify. Inform affected customers without undue delay and no later than 72 hours after confirming an incident affecting their data, and comply with applicable state breach-notification law. Where bank connection data is implicated, notify Plaid.
4. Remediate and review. Correct the cause, then record what happened, what was done, and what control change prevents a recurrence.

Customers can report a suspected security issue to business@sanctifo.com. We will acknowledge a report within two business days.

12. Backup and recovery

Database backups are performed automatically by Supabase with point-in-time recovery available on the production instance. Application code is recoverable in full from version control. Because all infrastructure is defined in code and hosted on managed platforms, the service can be rebuilt from source and a backup.

13. Vendor management

We rely on a deliberately small number of subprocessors, each selected in part for its own security posture. As of the date above: Vercel (application hosting), Supabase (database, authentication, storage), Plaid (bank connections), Stripe (payments), Anthropic (transaction categorisation) and Resend (transactional email). Each is a commercially established provider that maintains its own recognised security certifications.

Adding a subprocessor with access to customer data requires review of its security posture and an update to our published privacy policy.

14. Data minimisation, retention and deletion

We request only the data the product needs. Of the products Plaid offers, we request Transactions and nothing else, and only for the accounts a customer explicitly connects.

Customers can export all of their data at any time in an open format, and can disconnect a bank at any time, which revokes our access with Plaid immediately. On a deletion request we remove customer data from production within 30 days; residual copies expire from encrypted backups on the provider's backup cycle.

We do not sell customer data, aggregated data, or de-identified data, and we do not share it for advertising.

15. Endpoint and workstation security

Devices used to access production systems have full-disk encryption enabled, an automatic screen lock, and operating system updates applied. Production credentials are not stored on removable media. Customer data is not copied onto local machines in the ordinary course of work.

16. Personnel

The company currently has no employees. Before any person is granted access to production systems or customer data they will be subject to background screening appropriate to the role, a written confidentiality agreement, and security onboarding covering this policy. Access is revoked on the day a person departs.

Formal recurring security training will be established at the point there is a staff population to train.

17. Independent assessment

We hold no SOC 2, ISO 27001 or equivalent certification, and no third-party penetration test has been performed to date. Our infrastructure providers maintain their own SOC 2 Type II attestations; we do not represent those as our own. An independent assessment will be commissioned as customer volume and revenue justify it.

We state this plainly because a policy that implies certifications a company does not hold is worth less than no policy.

18. Compliance

We handle no cardholder data directly; payment processing is delegated in full to Stripe. Bank credentials are never transmitted to or stored by us; authentication takes place within Plaid's own interface. Our handling of customer financial data is governed by our privacy policy and terms of service.

Contact

Questions about this policy, or a security report, go to business@sanctifo.com.