Security at Spring
Businesses trust Spring with bank data, invoices and customer records. This page explains how we protect that information and how to tell us about a problem.
1. Our program
1.1 Spring runs a documented information security program. It covers access control, asset and data management, cryptography, secure development, operations security, vendor management, risk management, incident response, and business continuity.
1.2 We are working toward a SOC 2 report. Our controls are monitored continuously by an automated compliance platform, not checked once a year.
1.3 Every employee accepts our security policies and completes security awareness training when they join, and again each year.
2. Your data
2.1 Encrypted in transit. All traffic to spring.ai and the Spring platform uses HTTPS with TLS.
2.2 Encrypted at rest. Production databases and their backups are encrypted at rest.
2.3 Bank connections. Bank accounts connect through Plaid. Your bank username and password go to Plaid, never to Spring.
2.4 Private by default. Production databases are not reachable from the public internet. They accept connections only from our own application servers on a private network.
2.5 Deletion. You can ask us to delete your data. See the Privacy Notice for your rights and how to use them.
3. Infrastructure
3.1 Spring is hosted on Amazon Web Services in the United States. AWS data centers hold their own independent security certifications.
3.2 Administrative access to servers runs over a private, device-authenticated network. No administrative port is open to the internet.
3.3 Firewall rules are managed as code, so every change is recorded and reviewed. We review the full ruleset at least once a year.
3.4 Databases are backed up automatically, and we keep a disaster recovery plan.
4. Access
4.1 Company accounts require two-step verification.
4.2 Access to production follows least privilege. We review who has access to our critical systems every quarter and remove what is no longer needed.
4.3 Access keys are rotated on a fixed schedule, and access is removed when someone leaves.
5. How we build
5.1 Every change to the Spring platform ships through a pull request and must pass a suite of automated checks before it can reach production.
5.2 We scan our software dependencies for known vulnerabilities continuously, and fix findings against defined timelines.
5.3 Secrets are kept in a managed secrets store, never in source code.
6. Incidents
6.1 We maintain an incident response plan. After any significant incident we write up the root cause and the fixes.
6.2 If an incident affects your data, we will notify you as the law and our agreements require.
7. Report a vulnerability
7.1 If you believe you have found a security issue in a Spring product, email security@spring.ai. Include the steps to reproduce it and the impact you see.
7.2 We will confirm receipt within three business days and keep you informed while we investigate.
7.3 Please act in good faith. Do not access or change data that is not yours, do not degrade the service for others, and give us reasonable time to fix the issue before you share it publicly. We will not take legal action against researchers who follow these guidelines.
7.4 Spring does not run a paid bug bounty program today. We are glad to credit researchers who report valid issues.
7.5 Our machine-readable disclosure policy is at /.well-known/security.txt.