TrueTally

Information Security Policy & Procedures

Owner-authored policy · Version 1.0 · Last reviewed September 2, 2026 · Next review due within 12 months

This document describes the security controls that are in place and operating for the TrueTally application. It is maintained by the application owner and reflects the implementation of the live system. It does not assert any third-party audit, certification, or regulatory attestation.

1. Purpose and scope

This policy documents how TrueTally ("we") identifies, mitigates, and monitors information security risks across the TrueTally web application, its managed cloud database, and the third-party services it relies on (payment processing and bank data aggregation).
It applies to all personnel with access to production systems and to all customer data processed by the application, including account, transaction, invoice, and bank-connection records.
The policy is reviewed at least annually and after any material change to the architecture, the data we process, or the vendors we use.

2. Roles and responsibilities

The business owner acts as the security officer and is accountable for approving this policy, granting and revoking production access, and responding to security events.
Anyone granted production access is responsible for following this policy, using unique credentials with multi-factor authentication, and reporting suspected incidents immediately.
Vendor security posture (hosting, database, payments, bank aggregation) is the responsibility of the security officer to review before onboarding and at least annually thereafter.

3. Risk identification and assessment

A written risk assessment is performed at least annually and whenever a new data type, integration, or feature that touches financial data is introduced.
Each risk is recorded with its threat, affected asset, likelihood, impact, existing control, and residual risk rating.
Primary risks tracked today: unauthorized access to customer financial records, exposure of bank access tokens, credential compromise of an administrative account, forged inbound webhooks, insecure dependencies, and vendor compromise.
Risks rated high are assigned a remediation owner and target date; risks accepted without remediation are documented with a written justification.

4. Access control

End users authenticate through the managed identity provider with email verification; passwords are stored and validated by the provider and are never handled by application code.
Phishing-resistant multi-factor authentication is available and operational for all end-user accounts: users enroll WebAuthn/FIDO2 passkeys (platform biometrics such as Face ID, Touch ID, or Windows Hello, or hardware security keys) from the in-app Security page. Credentials are origin-bound public-key pairs, so there is no shared secret or one-time code that can be replayed against a look-alike site.
When an account has an enrolled passkey, the identity provider raises the required authenticator assurance level to AAL2 and the application completes a WebAuthn assertion after the first factor before granting access to any account data; the session remains at AAL1 until the assertion succeeds.
Non-phishing-resistant multi-factor authentication is also performed and available to all end users: time-based one-time password (TOTP) authenticator apps such as Google Authenticator, Authy, or 1Password can be enrolled from the in-app Security page for devices or browsers that cannot use passkeys. Enrollment requires the user to prove possession by submitting a valid code before the factor becomes active, and codes are validated by the identity provider with a bounded time window and replay protection.
Where both are enrolled, the application presents the passkey first and treats the one-time code as the fallback path; either factor satisfies the AAL2 requirement enforced at sign-in. Email verification of the account address is required at signup as an additional non-phishing-resistant identity check.
SMS-based one-time codes are not used for privileged access, and no knowledge-based question-and-answer factor is used, because both are weaker than TOTP against interception and social engineering.
Administrative and vendor accounts (hosting, database, payment processing, bank aggregation, source control, email) use phishing-resistant MFA — passkeys or hardware security keys — with a TOTP authenticator app as the backup second factor where a vendor does not support security keys.
Every customer-facing database table enforces row-level security so a signed-in user can read and write only rows owned by their own user id. Access is denied by default when no policy matches.
Bank access tokens are stored only in a private table that is not exposed through the public data API. The application UI reads bank status through a restricted view that omits tokens entirely.
Privileged (service-role) database access is used only inside server-side handlers after the caller's identity has been verified, and is never shipped to the browser.
Administrative access to the hosting, database, and vendor dashboards is limited to the security officer, protected by multi-factor authentication, and reviewed at least quarterly. Access is revoked on the same business day that it is no longer needed.

5. Data protection

All traffic to the application and to third-party APIs is served over TLS; the published site is HTTPS-only.
Data at rest is stored in the managed cloud database, which applies provider-managed encryption at rest and automated backups.
Plaid access tokens, synchronization cursors, and retained raw Plaid account and transaction payloads are additionally encrypted by the application with AES-256-GCM before database storage. The encryption key is held separately in the platform secret store and is available only to server-side code.
New Plaid syncs write encrypted payloads, and the sync path backfills legacy Plaid rows before use. Encrypted values use a versioned format to support controlled future key rotation.
Secrets (API keys, provider secrets) are held in the platform's encrypted secret store, injected at runtime into server-side handlers only, and are never committed to source control or exposed to the client bundle.
The application requests only the bank data required to deliver its features (account balances and transactions) and does not sell or share customer financial data with third parties for marketing.
Customer data is retained while the account is active. Disconnecting a bank removes the stored connection and revokes the item with the aggregator; account deletion removes the associated records.

6. Secure development and vulnerability management

All changes are version-controlled, reviewed, and deployed through an automated build that must pass type checking and the production build.
Automated dependency and database security scans are run before release. High-risk findings are assigned an owner, patched or mitigated, and rechecked before deployment.
Production assets are monitored by the managed hosting provider and scanned for known vulnerabilities; operating-system, runtime and infrastructure patches are applied through the provider's supported update process.
Employee and contractor laptops used to access production systems must use managed endpoint protection, automatic operating-system and browser updates, full-disk encryption, screen lock, and phishing-resistant MFA. Devices are reviewed at onboarding and at least monthly for missing critical patches; access is revoked when a device falls out of compliance.
The security officer records scan dates, findings, remediation owners, due dates, exceptions and verification evidence in the security review record. Critical findings are handled immediately; high findings are targeted within 30 days.
Test and production data are kept separate; bank aggregation runs against the sandbox environment during development.

7. Privacy, consent and Plaid Link

The public Privacy Policy at /privacy explains the collection, processing, storage, sharing and deletion of account and Plaid Link data.
Account creation requires affirmative agreement to the Privacy Policy and consent to process account data. Before Plaid Link opens, the user must affirmatively consent to collection, processing and storage of the selected account, balance and transaction data.
Consent records store the policy version, consent type and timestamp under the user's account. The user may disconnect a bank, revoke consent by contacting the privacy address, or delete the account.
TrueTally uses Plaid only to provide the requested bank-connection experience and does not sell consumer financial data.

8. Third-party and webhook integrity

Inbound bank-aggregation webhooks are rejected unless they carry a valid provider signature: the signing key is fetched from the provider's key endpoint, the signature is verified, and a SHA-256 hash of the raw request body is compared against the signed claim.
Inbound payment webhooks are verified against the processor's signing secret before any state change is applied.
Every accepted webhook delivery is recorded with its provider event id in a service-role-only ledger, so replayed or duplicated deliveries are ignored.
Public endpoints perform their own authorization; no endpoint mutates data based on an unverified caller.

9. Monitoring and logging

Application and server-function errors, failed provider calls, and webhook verification failures are logged to the hosting platform's log stream and reviewed when alerts or customer reports arrive.
Bank connections record their last successful sync, error code, and error status, which surfaces degraded or revoked connections to both the operator and the customer.
Vendor dashboards (hosting, database, payments, aggregation) are monitored for anomalous request volume, authentication failures, and API errors.
Log review occurs on a weekly cadence at minimum and immediately following any suspected incident.

10. Incident response

Suspected incidents are reported to the security officer immediately at the contact address below.
Response follows five steps: contain (revoke credentials/sessions and disable the affected path), assess (determine what data and which users were affected), eradicate and recover (patch, rotate secrets, restore from backup if required), notify (affected customers and any affected provider, including bank aggregation and payment partners, without undue delay), and review (written post-incident record with corrective actions).
Provider API keys and webhook secrets are rotated as part of containment whenever compromise of a credential cannot be ruled out.
A written record is kept for every incident, including timeline, impact, and corrective actions taken.

11. Business continuity

The database is backed up automatically by the managed provider; restoration is performed from provider backups.
Application code and database migrations are stored in version control so the environment can be rebuilt and redeployed.
Recovery expectations are reviewed with the annual policy review.

12. Data retention and deletion

Retention principle: customer data is retained only while the account is active and only for as long as needed to deliver the service the customer asked for, to meet the customer's own recordkeeping needs, or to satisfy a legal or tax obligation. Data is not retained for resale, profiling, or advertising.
Retention schedule — Plaid connection data: access tokens, sync cursors, and retained raw Plaid account and transaction payloads are deleted when the customer disconnects the institution. Disconnecting also revokes the item with Plaid so no further data can be retrieved.
Retention schedule — imported and user-entered financial records (accounts, transactions, receipts, paychecks, invoices, bills, inventory): retained while the account is active, then deleted when the customer deletes the account or requests deletion. Customers may delete individual records at any time from the application.
Retention schedule — account and profile data: deleted on account deletion. Consent records (consent type, policy version, timestamp) are retained for up to 24 months after deletion as the record of lawful basis, then deleted.
Retention schedule — security, webhook, and error logs: retained for up to 90 days for security monitoring and troubleshooting, then rotated out by the platform. Webhook delivery ledger entries retain only provider event identifiers, never consumer financial content.
Retention schedule — backups: managed provider backups follow the provider's rolling backup window, so deleted records age out of backups within that window rather than persisting indefinitely.
Enforcement: deletion is enforced technically, not only by policy. Bank disconnection deletes the connection row (and its encrypted token, cursor, and payload columns) inside a server-side handler and revokes the Plaid item in the same operation. Customer-owned records reference the account identity with cascading deletes, so removing the account removes the dependent rows in the database rather than leaving orphaned data.
Customer rights requests (access, correction, deletion, consent revocation, or export) are accepted at privacy@truetally.ai and are acknowledged within 5 business days and completed within 30 calendar days, consistent with applicable data privacy laws including GDPR and the CCPA/CPRA where they apply. Requests are verified against the account holder before any data is released or erased.
Legal hold: where a law, regulation, or active legal claim requires retention, the affected records are isolated and retained only for that purpose, and the customer is informed that erasure is delayed for that reason.
Periodic review: this retention and deletion policy is reviewed by the security officer at least annually, and additionally whenever a new data type, integration, or vendor is introduced or an applicable privacy law changes. Each review verifies that the schedules above match the live system and that test deletions actually remove the intended rows; the review date, reviewer, and findings are recorded in the security review record.

13. Vulnerability scanning and patch management

Yes — vulnerability scanning is actively performed against both personnel endpoints and production assets, and findings are tracked to remediation.
Production application dependencies: an automated dependency vulnerability scan (npm audit based) is run against the full dependency tree before every release and at least monthly. High and critical findings are patched by upgrading the affected package, or mitigated and documented with an expiration date if no fix is available.
Production database and backend: an automated backend security scan (RLS coverage, table and view exposure, policy and grant misconfiguration, function search paths, auth configuration) plus the database platform's linter are run before every release and at least monthly. Findings are remediated by migration and rescanned to verify closure.
Production infrastructure: the application, database, and edge runtime are managed platform services. The provider performs continuous infrastructure and operating-system vulnerability scanning and patching; we apply platform-published runtime and image updates on release and verify the deployed runtime versions during the monthly review.
Web application surface: TLS configuration, security headers, authentication flows, and public endpoints are re-tested after each material change, and public routes are reviewed for unintended data exposure during the same monthly cycle.
Employee and contractor machines: every laptop with access to production systems runs endpoint protection with continuous vulnerability and malware scanning, automatic operating-system and browser patching, full-disk encryption, screen lock, and phishing-resistant MFA. Device posture (patch level, encryption, endpoint agent health) is verified at onboarding and reviewed at least monthly; a device that fails the check has production access revoked until it is remediated.
Remediation targets: critical findings are remediated or mitigated within 7 days, high within 30 days, medium within 90 days, and low at the next scheduled maintenance. Exceptions require written approval, a compensating control, and an expiration date.
Evidence: scan date, tool, scope, findings by severity, remediation owner, completion date, and rescan verification are recorded in the security review record and retained for at least 12 months.
Reporting: suspected vulnerabilities may be reported to security@truetally.ai; reports are acknowledged within 5 business days and triaged under the remediation targets above.

14. Policy exceptions and enforcement

Exceptions to this policy require written approval from the security officer, a documented compensating control, and an expiration date.
Failure to follow this policy results in revocation of production access.

15. Plaid OAuth redirect URI configuration

Banks that require a separate OAuth sign-in return the user to a dedicated, registered redirect URI rather than an arbitrary page. The application uses a single stable redirect endpoint at /plaid-oauth (for example https://truetally.ai/plaid-oauth on the published site) for every Plaid Link session that may require OAuth.
The exact redirect URI is sent to Plaid when each Link token is created (redirect_uri on /link/token/create), and the same URI is registered in the Plaid developer dashboard under the relevant environment (production). Plaid rejects a redirect to any URI that is not registered, so the registered set is the authoritative list and is reviewed at least annually.
The /plaid-oauth page is the only landing target for the OAuth return. It reads the Plaid oauth_state_id returned in the query string, retrieves the Link token that was saved to session storage before the redirect, and resumes Plaid Link in place with the full receivedRedirectUri. No bank credentials are ever present on the redirect URI or in its query string.
If no oauth_state_id is present or no Link token is found, the page redirects the user back to the accounts page without attempting a connection, so the endpoint cannot be abused to initiate an unrequested link.
The redirect URI uses HTTPS on the published site, is marked noindex so it is not indexed or advertised as a navigable page, and is reviewed whenever the application domain or Plaid environment changes.