Information Security Policy

Purpose & scope

Protect the confidentiality, integrity, and availability of the information RWBS holds — above all the financial and business data our clients entrust to us in the course of bookkeeping and business-automation work.

This policy applies to information wherever RWBS handles it, not to any one product:

• Company Systems — the platforms, accounts, devices, repositories, and third-party services RWBS operates to run its own business and to deliver client work, including the internal business system in which client bookkeeping is performed.
• Client Systems — systems, code, repositories, integrations, and infrastructure that RWBS builds, deploys, administers, or is granted access to on a client's behalf, including those owned by and hosted in the client's own accounts and kept entirely separate from Company Systems.
• Client Data — records, documents, credentials, and derived information belonging to a client, in either location.

The safeguards below apply to Client Data by default, regardless of which system it sits in or who owns that system. Where a client's own written security requirements are stricter, those govern for that engagement.

This policy is designed to align RWBS's safeguards with the standards of the FTC Safeguards Rule (16 CFR Part 314) under the Gramm-Leach-Bliley Act, and to meet RWBS's contractual obligations under the Plaid Developer Policy.

Roles & responsibilities

The Owner is accountable for information security: setting policy, granting and revoking access, managing vendors, responding to incidents, and the annual review. Everyone who performs work for RWBS — today the Owner; in future any employee or contractor — is responsible for following this policy, and is bound to it before receiving access to Client Data. Security reports and disclosures go to security@rw-businessservices.com (monitored).

Data classification

• Restricted — client financial data and credentials: bank transactions, balances, statements, receipts, tax and payroll records, financial-account identifiers, Plaid access tokens and item/account IDs, and any credential granting access to a client's systems. Highest protection; encrypted at rest and in transit; least-privilege access; never logged in plaintext; never exposed to client-side code.
• Confidential: other client business records and correspondence, client source code and system designs, RWBS business and financial records, CRM data, secrets and credentials.
• Internal: operational documentation and non-client code.
• Public: marketing and website content.

Client Data is classified Restricted or Confidential in all cases — never Internal — whichever tier its sensitivity warrants.

Identity & access management

• MFA everywhere. Phishing-resistant MFA (passkeys, biometrics, or hardware keys where supported) is enabled on every account with access to Restricted or Confidential data: Google Workspace, Vercel, Neon, GitHub, the Plaid Dashboard, the secrets/password manager, and any client-issued account where the client's platform supports it.
• Least privilege & unique accounts. Each person or service has its own identity; no shared logins. Access is granted only for a clear business need and revoked promptly when no longer needed.
• Application auth. RWBS-operated applications are gated by Google OAuth SSO (NextAuth); non-human and machine calls use scoped bearer secrets or OAuth tokens, never shared passwords.
• Access review. Reviewed at least annually and whenever roles change.
• Detail. Roles, provisioning and revocation, privileged access, machine identities, access to client environments, and the review procedure are specified in the Access Control Policy, which governs wherever it is more specific than this section.

Client engagements & client-operated systems

Work performed for a client is held to this policy even when it lives outside RWBS's own accounts:

• Separation. Each client's code and data are kept in separate repositories and separate environments — never commingled with another client's, and never commingled with RWBS's internal systems. A credential issued for one engagement is used only for that engagement.
• Client-issued access. Where a client grants RWBS access to their systems, RWBS uses named individual accounts (never a shared client login), at the least privilege that accomplishes the work, protected by MFA where the client's platform offers it. RWBS does not copy Client Data out of a client's environment except as the engagement requires.
• Delivered systems. Software RWBS builds for a client is developed under the Secure development practices below — private repositories, secret scanning, no credentials in code, dependency scanning — and is delivered with its secrets held in the client's own secret store rather than in RWBS's.
• Offboarding. At the end of an engagement, RWBS returns or deletes Client Data per the Data Retention & Deletion Policy, hands over ownership of delivered code and infrastructure as agreed, and its access to client systems is revoked and any shared secret rotated.

Secrets management

Secrets (API keys, database URLs, encryption keys, refresh tokens, client-issued credentials) live only in a platform secret store or a reputable password manager — never in source code, tickets, or chat. Automated secret scanning runs on every RWBS repository, internal and client-facing, and blocks a commit containing credentials before it leaves the machine. Secrets are rotated on suspected exposure, on any staff or vendor change, and at the end of a client engagement.

Encryption

• In transit: TLS 1.2+ only for all traffic (Vercel HTTPS with HSTS; Neon, Plaid, and Google APIs are TLS-only).
• At rest: the financials database (Neon Postgres) is encrypted at rest (AES-256). Financial-account access tokens are additionally encrypted at the application layer with AES-256-GCM before storage, with the key held only in the platform secret store and never in the database. Documents are stored in Google Drive, encrypted at rest by Google.

Endpoint security

Work devices use full-disk encryption (FileVault), automatic OS and security updates, a screen lock with a short timeout, and a supported OS version. Devices are not shared. Client Data is not stored on removable media or on personal devices.

Vulnerability & patch management

• Scanning. Automated dependency scanning (GitHub Dependabot) plus npm audit runs across all RWBS repositories, internal and client-facing, alongside automated secret scanning. Vulnerabilities affecting a client-delivered system are reported to that client.
• Remediation SLA. Identified vulnerabilities are remediated within defined windows, measured from the date RWBS becomes aware of them:

• Where the window cannot be met. If no upstream fix exists, RWBS records the exposure, applies a mitigation or compensating control where one is available, and tracks it to closure rather than letting it lapse silently. Where a vulnerability is not reachable in the way RWBS uses the affected component, that assessment and its reasoning are documented, and the update is applied on the normal maintenance cycle instead of the accelerated window.
• Platform, OS, and managed-service patching is handled by the vendors (Vercel, Neon, Google) and by endpoint auto-update.

Secure development

• Private repositories only — for internal and client work alike. Client work is kept in its own repository, separate from RWBS's internal codebase.
• Changes ship through review gates (automated reviewers and a passing build) before production.
• No secrets in code; input from external sources is sanitized; spreadsheet writes use RAW mode to prevent formula injection; the accounting ledger enforces double-entry integrity at the database.
• Automated components may propose changes to financial records; only an authenticated human may approve and post them.

Vendor & subprocessor management

Restricted and Confidential data is entrusted only to reputable providers with their own security programs: Vercel (hosting), Neon (database), Google (auth, Drive, Sheets), Plaid (financial-account connectivity), Resend (email), and Anthropic (AI). Providers are selected for their demonstrated ability to safeguard the data entrusted to them, are contractually required (under their data-processing terms) to maintain appropriate safeguards, and are reassessed at least annually and on any material change. Our processing subprocessors — Google, Vercel, Neon, Resend, and Anthropic — use RWBS and client data only to provide services to RWBS, under contract, and not for their own purposes, including to train their own models. Plaid handles financial-account connection data as an independent controller under its own End User Privacy Policy. Where an engagement requires a vendor a client has selected, that vendor is governed by the client's own agreement with them.

Logging & monitoring

Security-relevant changes to financial data are recorded in an append-only audit log, immutable at the database. Platform logs (Vercel, Google, GitHub, Neon) are available for investigation. Access to the Plaid Dashboard and to production systems is limited and monitored.

Backup & recovery

The financial book-of-record (Neon Postgres) is protected by point-in-time restore across a 7-day retained history window, enabling recovery to a prior moment after accidental deletion, data corruption, or a faulty change. Documents and spreadsheet data retain provider-side version history (Google Drive and Sheets). Recovery data inherits the same encryption and access controls as production. The Owner validates that a restore works at least annually and records it in the audit/attestation log. Backup of a client-owned system is the client's responsibility unless the engagement states otherwise in writing.

Incident response & breach notification

On a suspected security incident:

1. Contain — rotate affected secrets and encryption keys, revoke compromised sessions and credentials, and invalidate exposed financial-account tokens via the provider (for Plaid, /item/access_token/invalidate).
2. Assess scope using the audit log and platform logs, and determine whose data is affected.
3. Notify affected clients promptly — without undue delay after confirming an incident involving their data — with what is known, what is affected, and what we are doing about it, and cooperate with any notification the client must make.
4. Notify Plaid promptly at security@plaid.com for any breach or unauthorized use of financial-account data obtained through Plaid.
5. Notify other affected parties and regulators as required by law.
6. Remediate and record lessons learned.

Data retention & deletion

Governed by the Data Retention & Deletion Policy, including return or deletion of Client Data at the end of an engagement and deletion of financial-account connections at the provider.

Risk management & review

The Owner reviews risks and this policy at least annually, updating controls as the business grows. Controls that are prerequisites, not aspirations: before RWBS offers self-service access to a system in which multiple clients' data is stored together, per-tenant data isolation enforced at the database and multi-factor authentication before a client links a financial account will be in place. RWBS will not take on that mode of operation ahead of those controls.

Acceptable use

Company Systems, Client Systems, and the data in them are used only for legitimate business purposes, only as the client has authorized, and in line with this policy and applicable vendor terms.