What we treat as an incident
We define a security incident as any confirmed or reasonably suspected event that compromises the confidentiality, integrity, or availability of the Valty platform or the customer data it holds. Because source-of-truth security systems remain with the customer, the data inside Valty is limited to normalized, tenant-isolated proof objects rather than raw security telemetry; an incident therefore centers on unauthorized access to, alteration of, or loss of those proof objects, our application, or the supporting infrastructure (Vercel for hosting and CDN, Neon for the Postgres database, and Upstash for rate-limiting and queueing). We distinguish incidents from routine events such as blocked login attempts, rate-limited traffic, or single-component degradation that does not expose data, which are handled as operational matters and do not by themselves trigger customer notification.
How we respond: detect, contain, eradicate, recover, review
Our response follows the standard five-phase lifecycle, executed by a small core team given our stage. Detect: we monitor application, platform, and subprocessor signals and review credible third-party and customer reports. Contain: we move to limit blast radius first, for example by isolating affected components, revoking credentials or sessions, and relying on tenant isolation to prevent cross-customer exposure. Eradicate: we identify and remove the root cause, such as revoking compromised access, patching the vulnerability, or removing malicious artifacts. Recover: we restore affected services to a known-good state and validate integrity before returning to normal operation. Review: every confirmed incident is followed by a post-incident review. As an early-stage team we do not operate a 24/7 staffed SOC, and we are honest that detection and response times depend on team availability rather than a contracted around-the-clock rotation.
Customer notification commitments
For a confirmed security incident that affects a customer's data, we commit to notifying that customer without undue delay and, as a target, within 72 hours of confirming that their data was affected. Notification will describe what we know at the time, including the nature of the incident, the categories of data involved to the extent known, the steps we have taken to contain and remediate it, and any recommended actions on the customer's side. Because investigations evolve, an initial notice may be preliminary and followed by updates as facts are established. This 72-hour target is our current operating commitment as an early-stage provider; specific contractual notification terms, where they exist, are governed by the agreement between Valty and the customer and take precedence over this summary.
Communication channel
We notify affected customers through their designated security or administrative contact, primarily by direct email sent via our transactional email provider, Resend, and through direct contact with the relevant person at the customer's organization. Customers can reach us about a suspected incident or report a vulnerability by emailing security@valty.ai. We ask design partners to keep a current security contact on file so that, in the event of an incident, we can reach the right person quickly. Status of any platform-wide availability issue may also be communicated directly to affected accounts.
Post-incident review
After a confirmed incident is resolved, we conduct a post-incident review focused on root cause, the effectiveness of detection and containment, and concrete corrective actions to reduce the likelihood and impact of recurrence. Where the incident affected a customer's data, we share a summary of findings and remediation with that customer on request. Lessons learned feed back into our controls, monitoring, and this response process. We are candid that this review function is currently lightweight and conducted by the core team rather than a dedicated incident-response organization, and that maturing it is part of our broader security roadmap.
Maturity and roadmap context
Valty is stage-honest about where this program sits. We do not hold a completed SOC 2 report; SOC 2 and related formalization are on our roadmap, not finished. The practices above describe a real but maturing program operated by a small team, not a fully audited, continuously staffed incident-response capability. As the company grows, we intend to formalize detection coverage, response staffing, documented runbooks, and independent attestation, and we will update this summary to reflect those changes rather than overstating our current state.