Service Level Agreement
Steve platform · Trissino Inc.
1. Purpose
This Service Level Agreement (“SLA”) sets out the availability, support and remediation commitments that Trissino makes to Customers of the Steve platform. Its purpose is to state, in measurable terms, what Customers are entitled to expect and what remedies apply when Trissino falls short.
This SLA forms part of the Agreement between Trissino and the Customer. Where the Customer has executed a Master Services Agreement or an enterprise order form, the terms of that agreement prevail over this SLA to the extent of any conflict.
2. Scope
This SLA applies to:
- Availability of the Core Service, as defined in §3.
- Support and incident response, as set out in §8.
- Security vulnerability remediation, as set out in Annex B.
This SLA does not apply to:
- Free plans, trial accounts and proof-of-concept environments.
- Features designated beta, preview, early access or experimental.
- Any environment other than production.
- Third-party products the Customer connects to the Service, including, without limitation, Slack, Gong, Avoma, Outreach, Grain, Fireflies, Google Drive and CRM systems.
3. Definitions
“Core Service” means the Steve web application and its authenticated API, through which a Customer accesses competitive intelligence data, battle cards, playbooks, call analysis and reporting.
“Unavailable” means that, during a given five-minute measurement interval, the Core Service fails to respond to, or returns a server-side error in response to, correctly formed and properly authenticated requests from the Customer.
“Downtime” means the total number of minutes in a calendar month during which the Core Service was Unavailable, calculated as the sum of consecutive Unavailable measurement intervals and excluding every period listed in §6.
“Monthly Uptime Percentage” is calculated as:
Monthly Uptime % = (Total Minutes in Month − Downtime) ÷ Total Minutes in Month × 100
“Business Hours” means 09:00–18:00 Pacific Time, Monday through Friday, excluding United States federal holidays.
“Scheduled Maintenance” means planned maintenance notified in advance in accordance with §7.2.
“Incident” means an unplanned interruption to, or reduction in the quality of, the Service.
“Severity” means the classification assigned to an Incident under §8.1.
4. Availability commitment
Trissino shall provide the following Monthly Uptime Percentage for the Core Service:
| Plan | Monthly Uptime Commitment | Equivalent maximum monthly Downtime |
|---|---|---|
| Standard plans | 99.5% | Approximately 3 hours 39 minutes |
| Enterprise plan | 99.9% | Approximately 43 minutes |
This is a contractual commitment, not a target. Failure to meet it is a breach of this SLA.
Availability is measured and reported per calendar month, per Customer.
5. Measurement
5.1 Availability is measured by Trissino’s external monitoring, which polls the Core Service’s health endpoint and a representative authenticated transaction at intervals not exceeding five minutes, from at least two geographically distinct monitoring locations.
5.2 An interval is recorded as Unavailable only where failure is observed from more than one monitoring location, so that a fault in a single monitoring path is not counted against Trissino.
5.3 Trissino shall make availability measurements for the preceding twelve months available to an Enterprise Customer on written request, no more than once per quarter.
5.4 Where the Customer’s own monitoring records Downtime that Trissino’s monitoring did not, the Customer may submit that evidence to Trissino. Trissino shall consider it in good faith and shall not unreasonably reject corroborated Customer measurements.
6. Exclusions
Downtime does not include unavailability arising from:
a) Scheduled Maintenance notified in accordance with §7.2, that is, at least 72 hours in advance for Enterprise Customers and at least 24 hours in advance for all other Customers.
b) Emergency maintenance reasonably necessary to address an active security threat, where Trissino notifies the Customer as soon as practicable and in any event within 4 hours of commencing it.
c) Force majeure, meaning events beyond Trissino’s reasonable control, including natural disaster, war, civil unrest, government action, and large-scale failure of internet infrastructure.
d) Failure of a third-party service that the Customer has connected to the Service, or failure of a Customer-side system, network or device.
e) Failure of an infrastructure sub-processor listed in Annex C, where the failure is attributable to that sub-processor and not to Trissino’s configuration or operation of it. Trissino shall, at an Enterprise Customer’s request, pursue available remedies under its own agreement with the sub-processor.
f) Customer action, including misuse, unauthorised modification, exceeding documented rate limits, or use of the Service otherwise than in accordance with the Documentation and the Agreement.
g) Suspension of the Customer’s account in accordance with the Agreement, including for non-payment.
7. Scheduled maintenance
7.1 Trissino shall perform Scheduled Maintenance outside Business Hours wherever practicable.
7.2 Trissino shall give Enterprise Customers at least 72 hours’ advance notice, and all other Customers at least 24 hours’ advance notice, of any maintenance expected to cause unavailability.
7.3 For Enterprise Customers, Trissino shall make reasonable efforts to schedule maintenance outside 09:00–18:00 Japan Standard Time where the Customer’s primary operations are in Japan.
7.4 Trissino shall not perform non-emergency Scheduled Maintenance during a period the Customer has designated in advance as a business-critical freeze window, up to four such windows per calendar year.
8. Support and incident response
8.1 Severity classification
| PX | Severity | Definition |
|---|---|---|
| P1 | Critical | The Core Service is completely unavailable, or a core function is unusable, for all or substantially all of the Customer’s users, with no workaround. |
| P2 | High | A major feature is unavailable or materially degraded for many users, or a workaround exists but imposes significant operational burden. |
| P3 | Medium | A minor feature is impaired, or a problem is intermittent, with a reasonable workaround available. |
| P4 | Low | General inquiries, cosmetic defects, documentation issues, feature requests. |
Trissino assigns Severity on receipt. Where the Customer disputes the assignment, the higher of the two proposed Severities applies until the dispute is resolved in writing.
8.2 Response and restoration targets
Times are measured in Business Hours except where stated as elapsed hours.
| Severity | Initial response | Target restoration or workaround | Update cadence |
|---|---|---|---|
| P1 | 1 hour, 24x7 | 4 elapsed hours | Every 4 hours until resolved |
| P2 | 4 Business Hours | 12 elapsed hours | Daily |
| P3 | 8 Business Hours | 3 business days | On material change |
| P4 | 1 business day | As agreed | On material change |
“Initial response” means substantive acknowledgement by a person able to act on the Incident, not an automated receipt. “Target restoration” means restoration of service or provision of a workaround that removes the material business impact; it is a target.
P1 response is provided on a 24x7 basis and is not limited to Business Hours.
8.3 Support channels
| Channel | Purpose | Availability |
|---|---|---|
| Slack Connect | Primary channel for all Severities | Monitored during Business Hours; P1 paging 24x7 |
| gagan@trissinoai.com | All Severities | Monitored during Business Hours |
| tech@hiresteve.ai | Security incidents and vulnerability reports | Monitored 24x7, with on-call paging |
| tech@hiresteve.ai | Data subject requests and privacy inquiries | DSRs within 30 days; other inquiries within 5 business days |
8.4 Incident communication
For P1 Incidents, Trissino shall:
- a) notify affected Customers within 4 hours of declaring the Incident;
- b) provide status updates at least every 4 hours until service is restored;
- c) provide a written root cause analysis within 10 business days of resolution.
8.5 Customer responsibilities
The Customer shall:
- a) report Incidents through a channel listed in §8.3, with sufficient detail to reproduce and diagnose the issue;
- b) nominate and maintain a primary technical contact;
- c) respond to reasonable requests for diagnostic information, it being understood that Trissino’s response and restoration targets are suspended for any period during which Trissino is awaiting information reasonably requested from the Customer;
- d) ensure its systems meet the documented minimum technical requirements;
- e) use the Service in accordance with the Agreement.
9. Security and compliance
9.1 Independent assurance. Trissino maintains a SOC 2 Type 2 attestation covering the Security, Confidentiality and Availability Trust Services Criteria. The most recent report, issued by Securance Pro Assurance PLLC for the period 1 October 2025 to 31 December 2025, was unqualified with no exceptions noted. Trissino shall provide the report, and a bridge letter covering the period since, to an Enterprise Customer under NDA on written request, no more than once per twelve months.
9.2 Penetration testing. Trissino commissions an independent penetration test of the application at least annually and on material architecture change. The most recent test was performed by Bubba AI, Inc. on 30 November 2025 and returned no Critical, High or Medium findings. A summary is available to Enterprise Customers under NDA.
9.3 Vulnerability remediation. Trissino remediates security vulnerabilities in accordance with the SLA set out in Annex B.
9.4 Encryption. Data is encrypted in transit using TLS 1.2 or 1.3, with TLS 1.0 and 1.1 refused, and at rest using AES-256 across all subsystems. Customer-supplied encryption keys are not supported at this time.
9.5 Access control. Multi-factor authentication is mandatory for all administrative and remote access. Standing production administrative access is limited to the Chief Technology Officer. Temporary privilege elevation expires automatically within 24 hours. Audit logs are retained for at least 90 days online and at least one year archived.
9.6 Security incident notification. Where Trissino confirms a security incident affecting Customer data, it shall notify the Customer without undue delay and in any event within 48 hours of becoming aware, in accordance with the Data Processing Agreement.
10. Continuity and recovery
10.1 Trissino maintains a documented Backup, Business Continuity and Disaster Recovery Policy, and conducts tabletop exercises at least annually.
10.2 Production database backups are taken daily, with point-in-time recovery enabled and at least 30 days of online retention. Backups are encrypted with AES-256 and held in a geographically separate region.
10.3 Restore testing is performed at least quarterly for critical systems.
10.4 Recovery time and recovery point objectives by subsystem are set out in Annex A.
11. Data protection
11.1 Residency. Customer data is stored and processed in North America. Any change to data residency is a material service change and shall be notified in advance in accordance with the Agreement and the Data Processing Agreement before any cross-region transfer occurs.
11.2 Deletion on termination. On termination or expiry, Trissino disables Customer access immediately, provides a read-only export window for 30 days, and executes its deletion runbook at day 30, issuing written confirmation of deletion. Destruction follows NIST SP 800-88 Rev. 1.
11.3 Sub-processors. Trissino’s sub-processors are listed in Annex C. Trissino shall give at least 30 days’ advance notice of the addition or replacement of any sub-processor, during which the Customer may object on reasonable data-protection grounds.
11.4 No training on Customer data. Trissino does not train artificial intelligence models. Trissino does not use Customer Data to train, fine-tune, develop, improve, evaluate or benchmark any model, and does not sell, rent or share Customer Data. Every AI provider engaged as a sub-processor is contractually required to apply zero data retention, or short-lived processing-only retention. Any change to this commitment requires the Customer’s prior written consent and an updated Data Processing Agreement.
11.5 Japan. Where the Customer is established in Japan or processes personal information subject to the Act on the Protection of Personal Information, Annex D applies.
12. Limitations
This SLA does not cover any failure arising from:
- a) internet connectivity outside Trissino’s infrastructure;
- b) the Customer’s own hardware, software, network or configuration;
- c) misuse or unauthorised modification by the Customer or its users;
- d) third-party services integrated at the Customer’s election;
- e) beta, preview or experimental features;
- f) any matter listed in §6.
13. Changes to this SLA
13.1 Trissino may amend this SLA from time to time. Material changes shall be notified at least 30 days before they take effect.
13.2 Where a material change would reduce the availability commitment in §4, an Enterprise Customer may, within 30 days of notice, elect to continue under the then-current version for the remainder of its then-current subscription term.
13.3 The current version is published at https://www.hiresteve.ai/legal/sla.
14. Precedence
In the event of conflict, the following order of precedence applies: the executed Master Services Agreement or order form; the Data Processing Agreement, in respect of personal data; this SLA; the Terms of Service.
15. Contact
Trissino Inc.
1151 Walker Rd PMB 484, Dover, DE 19904, United States
Support: gagan@trissinoai.com
Security, monitored 24x7: tech@hiresteve.ai
Privacy: tech@hiresteve.ai
16. Acceptance
By subscribing to, accessing or continuing to use the Service, the Customer acknowledges that it has read and understood this SLA, and agrees to be bound by its terms as though set forth herein in full.
Annex A: Recovery objectives
| System | Function | RTO | RPO |
|---|---|---|---|
| Vercel | Web application and API | 1 hour | 0 |
| Clerk | Authentication | 1 hour | 0 |
| Turso | Production database | 4 hours | 15 minutes |
| AWS S3 | Object storage | 4 hours | 0 |
| AWS Lambda + SQS | Asynchronous processing | 4 hours | 30 minutes |
| Upstash | Cache | 4 hours | Best effort |
| Pinecone | Vector index | 8 hours | Best effort |
| GitHub / Actions | Build and deployment | 8 hours | 0 |
| Sentry / Rollbar | Error monitoring | 24 hours | Best effort |
| AI providers | Inference | 4 hours | Not applicable |
Maximum Tolerable Period of Disruption for authentication and for real-time platform usage is 4 hours.
Annex B: Vulnerability remediation SLA
| Severity | Triage | Remediation |
|---|---|---|
| Critical | ≤ 4 hours from report | 2 calendar days, or 24 hours where actively exploited or where multi-tenant isolation is affected |
| High | ≤ 1 business day | 5 calendar days |
| Medium | ≤ 3 business days | 10 calendar days |
| Low | ≤ 5 business days | 20 calendar days |
| Informational | Best effort | Backlog, no fixed SLA |
The remediation clock starts when a finding is confirmed and severity-classified, not at first report. For findings from automated tooling, it starts at the timestamp the tool emitted the alert. A disputed severity does not pause the clock; the higher proposed severity applies until resolved in writing.
Critical and High findings are remediated out of band by hot-fix deployment. Medium and Low findings may be included in the next scheduled release provided that release ships within the SLA window; otherwise they are cut out of band or covered by a documented compensating control.
Vulnerabilities in third-party dependencies are subject to the same SLAs once an upstream fix or workaround is available. Where no upstream fix exists, Trissino applies compensating controls within the SLA window and reassesses monthly.
A fix is remediated only once it is merged to the protected main branch and deployed to production, regression tests are added or a written exception is filed, and the original detection source no longer reports the issue.
Where a confirmed vulnerability has resulted in, or is reasonably likely to have resulted in, unauthorised access to Customer data, Trissino notifies affected Customers no later than 72 hours from confirmation, or sooner where contractually required. Where personal data is affected, the 48-hour notification in §9.6 applies instead.
Trissino targets closure within SLA of at least 95% of Critical and High findings, and at least 90% of Medium and Low findings.
Annex C: Sub-processors
| Sub-processor | Function |
|---|---|
| Vercel | Application and API hosting |
| Clerk | Authentication and identity |
| Turso | Primary database |
| Amazon Web Services | Object storage, queuing, compute, key management, audit logging |
| Pinecone | Vector index |
| Upstash | Cache |
| Sentry | Error monitoring, 90-day rolling retention |
| Rollbar | Error monitoring, 90-day rolling retention |
| GitHub | Source control and deployment |
| Google Workspace | Internal business systems |
| OpenAI | AI inference |
| Google AI | AI inference |
| Anthropic | AI inference |
| Perplexity | AI inference |
| Resend | Transactional email |
| Stripe | Billing |
All sub-processors operate under signed data processing agreements containing confidentiality, breach notification, data return and onward transfer provisions. AI provider sub-processors are contractually bound to zero data retention, or short-lived processing-only retention.