Security at Incremenza

Last Updated: September 10, 2026 Version: 1.6

Incremenza handles financial data, so security is not a feature we bolt on. This page describes the measures we have in place, honestly and without overstatement.

If you are completing a vendor security review, our Data Processing Addendum contains the same measures in contractual form, and our Sub-processor list names every third party involved in delivering the Service.

1. Encryption

In transit

All traffic between your browser and our servers is encrypted using TLS 1.2 or higher.
The platform is served exclusively over HTTPS. Unencrypted connections are refused.
All connections to third-party services, including Stripe, Plaid, QuickBooks, Square, and PayPal, are encrypted.
Certificates are managed with automatic renewal.

At rest

The production database is encrypted at rest, hosted on a managed database cluster with disk-level encryption enabled by default.
Integration tokens for connected services are encrypted using AES-256 before being written to the database.
Passwords are hashed using bcrypt with a work factor of 12. We never store passwords in a recoverable form, and we cannot see your password.
Automated daily backups are encrypted at rest, with point-in-time recovery available for the preceding 7 days.

Payment card data

Card data is handled exclusively by Stripe, a PCI DSS Level 1 certified processor.
Incremenza never stores full card numbers, security codes, or unencrypted card data.
We display only the last four digits, for your reference.

2. Authentication and access

Signing in

Administrators and managers are required to use phishing-resistant multi-factor authentication, a passkey (Face ID, Touch ID, Windows Hello, or a hardware security key). This is enforced before any access to the application, not scoped to particular areas. Administrators and managers are re-verified on every sign-in; there is no remembered-device exception for these roles. Browsers that cannot support passkeys fall back to an authenticator app.
Multi-factor authentication is required for all other users, who may choose either a passkey or an authenticator app.
Users who lose access to a device can register a new passkey through a signed, single-use, time-limited email link, or use a recovery code.
Administrators can reset a team member's MFA credentials, which requires the administrator to re-verify their own identity and notifies the affected user by email.
Optional single sign-on through Google or Microsoft, so you can enforce your own organization's authentication policy. Both providers are subject to the same authentication and multi-factor requirements described above.
Repeated failed sign-in attempts trigger a temporary lockout, and a notification is sent to the account owner.
Sign-in from a new country triggers an alert to the account owner.
Registering or removing a passkey triggers an email alert to the account owner.
Sessions use secure, httpOnly cookies with a same-site cookie policy, and expire after inactivity.
You can view your active sessions and sign out of other devices at any time.
One-time recovery codes are issued as an emergency fallback if your primary method becomes unavailable.
Credentials, trusted devices, and sessions are removed when an account is closed.

Separation between organizations

This is the control that matters most in a multi-customer platform.

Every customer organization's data is isolated by a mandatory scope applied automatically at the database query level. It is not something a developer can forget to apply.
Every request is authorized against the requesting user's organization before any data is returned.
Isolation is verified by automated tests that run continuously.

Roles

Admin: full access to company data, settings, billing, and team management
Manager: access to financial data, reporting, and team management, without billing or account deletion rights
User: access to dashboards and reports, without the ability to change settings

Users receive the minimum permissions their role requires. When you remove a team member, their active sessions are terminated immediately.

3. Integrations

All financial integrations use OAuth 2.0. You never share a password with Incremenza.
We request the minimum permissions required, and read-only access where the feature allows it. Most integrations are read-only. QuickBooks includes an opt-in write-back feature for transaction reconciliation, which can be disabled at any time.
Tokens are encrypted at rest.
OAuth flows use cryptographic state parameters to prevent request forgery.
Incoming webhooks are cryptographically verified against a signing secret. Unsigned or mismatched requests are rejected.
Duplicate webhook events are detected and ignored.

Disconnecting. You can disconnect any integration from your settings at any time. We revoke our tokens with the provider immediately, and the disconnection is logged. Previously imported data is retained so your historical records stay intact, and is deleted when you close your account.

4. Infrastructure

Hosted on DigitalOcean infrastructure, managed through Laravel Forge. Primary servers and the production database are located in San Francisco, California.
Application servers sit in private networks with restricted external access.
The production database runs on a dedicated managed cluster, reachable only over a private network from application servers. It is not exposed to the internet.
Infrastructure credentials can be rotated on demand; a routine rotation schedule is being formalized.
An additional, independently stored backup is maintained through a separate provider for redundancy, alongside the primary encrypted backups described in Section 1.
Product usage analytics are stored separately, in the European Union.

5. Application security

Server-side validation of all input.
Parameterized queries through an object relational mapper, preventing SQL injection.
Automatic output escaping, preventing cross-site scripting.
Cross-site request forgery protection on every state-changing request.
Automated dependency scanning for known vulnerabilities, governed by a documented vulnerability management policy with defined patch timelines by severity.
Regular updates to the framework, language runtime, and all dependencies.

6. Monitoring, logging, and incidents

Monitoring

Continuous application error and performance monitoring.
Known sensitive fields, including tokens, credentials, and payment data, are filtered from error reports before transmission.
Audit logging of authentication events and integration disconnections, retained for two years.
Failed authentication attempts are logged and monitored on an ongoing basis. See Section 2 for lockout behavior.

Staff access to your account

Authorized Incremenza personnel may access your account for support and troubleshooting. Every such access is logged with the person's identity, the account accessed, and the time and duration.

If something goes wrong

We maintain a documented incident response procedure, covering detection, containment, eradication, recovery, and post-incident review.
If a breach affects your personal data, we will notify you without undue delay, and within 48 hours of becoming aware of it. That timing is contractually committed in our Data Processing Addendum, and is set to give you time to meet your own regulatory deadlines.
After any incident we conduct a root cause review and implement preventive measures.

7. Availability

We aim to keep the Service reliable and perform maintenance outside peak hours where practical. We monitor system health and integration connectivity continuously. Automated daily backups are maintained for disaster recovery, with point-in-time recovery available for the preceding 7 days.

We do not currently publish a contractual uptime commitment. If your organization requires a service level agreement, contact us at [email protected] and we will discuss it.

8. Data handling in automated features

Some features use machine learning models operated by Google and Anthropic. We minimize what leaves our systems:

Personal details such as addresses and phone numbers are removed from merchant names before transmission.
Only aggregated financial summaries are sent for insight generation, never individual transaction records.
Account numbers, card numbers, and credentials are never sent.
Most transaction classification is resolved by internal matching against known merchants and learned patterns, so external models are the last step rather than the first. This substantially reduces how much data is transmitted.

We use paid enterprise tiers under agreements that prohibit training on customer data, and neither provider retains your data beyond the duration of the request.

9. Personnel

Personnel with access to customer data are bound by confidentiality obligations. Background checks are conducted for employees and contractors granted access to customer data, before access is granted. Access is limited to what each person's role requires, and all access to production systems is logged.

10. Compliance

Where we stand today

GDPR: a full Data Processing Addendum incorporating Standard Contractual Clauses is available and takes effect automatically. See our GDPR page.
CCPA and CPRA: we honor California privacy rights. We do not sell or share personal information.
PCI DSS: card processing is handled entirely by Stripe, PCI DSS Level 1 certified. Incremenza is out of scope for card data storage.
OAuth 2.0: used for all financial integrations.
Published sub-processor list with 30 days' advance notice of changes.

Certifications

We do not currently hold SOC 2 or ISO 27001 certification. We will pursue formal certification when customer requirements call for it, and we are happy to complete security questionnaires and provide documentation in the meantime.

We would rather tell you this plainly than imply a certification we do not have.

11. Your part

Security is shared. What we ask of you:

Use a strong, unique password, and enable multi-factor authentication
Never share credentials between people
Keep devices used to access Incremenza updated
Remove team members promptly when they leave your organization
Review connected integrations and access periodically
Be cautious of emails asking for your credentials. We will never ask for your password.
Report anything suspicious immediately

12. Reporting a vulnerability

If you find a security vulnerability, please tell us. We take reports seriously and will not pursue action against researchers who act in good faith under these guidelines.

Email: [email protected]

Please include a description of the issue, steps to reproduce it, and any supporting detail. We will acknowledge within 3 business days and keep you informed as we investigate.

Please do: test only against your own account, report promptly, and give us reasonable time to remediate before public disclosure.

Please do not: access or modify data belonging to others, run denial of service or destructive tests, use social engineering or phishing against our team or customers, or disclose publicly before we have had time to fix the issue.

13. Contact

Incremenza LLC

2108 N ST STE N Sacramento, CA 95816 United States

Vulnerability reports: [email protected] Privacy and data protection: [email protected] Support: [email protected]