Compliance and security

Stoney is built for teams that will eventually face a SOC 2 audit, or have already — and for buyers whose security team reads documentation before signing. This page explains how Stoney handles your data, what audit evidence it produces, and how it slots in alongside the compliance tools you’re already running.

There is nothing to install in your code for any of this. Stoney’s evidence is generated from the rule registry and the drift history it’s already maintaining — the same data the rest of the product runs on.

SOC 2 evidence Stoney produces

Stoney’s compliance export generates an auditor-ready evidence bundle covering two Trust Service Criteria that API-shipping companies have to satisfy:

CC7.1 — System operations and anomaly detection

Every drift event Stoney detected during the reporting period, with:

• The rule that broke and its plain-English statement
• The PR most likely to have caused the drift and its author
• The Jira ticket the change contradicted, if applicable
• The forensic confidence level and full reasoning paragraph
• Time-to-detect and time-to-resolve

This is the artifact auditors ask for when they want to see “evidence of anomaly detection.” Most teams produce it by exporting Datadog alerts and hand-narrating the resolution; Stoney produces it from the registry directly.

CC8.1 — Change management

Every approved rule with its authorizing Jira ticket, every PR check with its verdict and findings, every rule-approval action with the actor and timestamp, every escalation dispatch with the channel and outcome.

This is the artifact for “evidence that changes to production behavior were authorized and reviewed.” Auditors specifically look for the link between a code change and the business approval that authorized it — Stoney’s rule-to-ticket attribution is that link.

How to generate the bundle

From the dashboard:

1. Open Compliance.
2. Pick a reporting period — 7 days, 30 days, 90 days, 365 days, or a custom range.
3. Preview the metrics live: how many rules are enforced, how many drifts occurred, how many were resolved, what the median time-to-resolve is.
4. Click Download as JSON for a machine-readable bundle, or Download as Markdown for an auditor-readable document.

For exports that get shared outside your organization, the Redact paths toggle strips internal source-file paths from PR-check findings so the bundle doesn’t leak your code layout.

How Stoney slots in alongside Vanta, Drata, and Secureframe

Vanta, Drata, and Secureframe (and their peers) own the overall compliance workflow — the control checklist, the auditor portal, the policies repository, the evidence calendar. They don’t produce API-specific evidence because they don’t read your code or your tickets.

Stoney produces exactly that missing layer. The intended flow:

1. Vanta / Drata / Secureframe tracks your overall control posture and owns the auditor relationship.
2. Stoney generates the API-specific CC7.1 and CC8.1 evidence the compliance platform can’t produce on its own.
3. You attach Stoney’s evidence bundle to the relevant control in your compliance platform’s evidence library.

In every audit cycle we’ve seen, Stoney’s output is treated as supporting evidence under existing CC7.1 / CC8.1 controls — not as a separate audit artifact. Your auditor doesn’t need to know about Stoney specifically; they just see a high-quality evidence bundle attached to the right control.

Data handling summary

The full Privacy Policy lives at stoneydev.com/privacy. A quick summary of what matters technically:

• What we process. Route definitions, PR titles and bodies and diffs, Jira ticket text, the natural-language content of your rules. Sent to Anthropic (for synthesis and PR analysis) and Voyage AI (for embeddings). Both providers contractually commit not to use inputs for model training.
• What we persist. The derived rule registry, drift forensics reports, escalation records, and the audit log. We do not persist your full source code — only the specific diff excerpts that appear in forensic reports as evidence.
• Integration credentials. GitHub App installation IDs, Slack bot tokens, and Jira OAuth tokens are encrypted with AES-256-GCM using a server-side key before being written to the database.
• Retention. Rules live for the lifetime of your org; forensic reports cache 24h; server logs 30 days; the audit log is retained for 7 years to satisfy SOC 2 requirements; backups age out after 7 days.

Encryption and access control

In transit. All connections use TLS 1.3. HTTP requests redirect permanently to HTTPS.

At rest. All data is encrypted at rest via the managed Postgres provider. Integration credentials are additionally encrypted with AES-256-GCM before being written.

Org scoping. Every query in Stoney is filtered by the requesting user’s organization. Cross-org reads are impossible from any application path.

Role-based access. Owners and admins can approve rules, override owners, export compliance evidence, trigger contradiction scans, and manually escalate drift. Members can view but not mutate.

Least-privilege integrations. GitHub App access is scoped to the repositories you select — not your entire organization. Jira OAuth is read-only by default; issue creation is opt-in. Slack scopes are the minimum needed for DM and channel posting.

Rate limiting. Every state-mutating endpoint has per-user, per-org rate limits enforced at the request layer. Abuse (e.g. spam-approving rules) is blocked.

Sub-processors

The full list is in the Privacy Policy. Quick reference:

All sub-processors operate under contractual terms that prohibit training AI models on your data and require appropriate security controls.

Incident response

• Report security issues to security@stoneydev.com. We acknowledge within 48 hours.
• Critical vulnerabilities trigger an immediate patch; affected customers are notified via in-app banner and owner email.
• Material security incidents affecting customer data are disclosed within 72 hours per GDPR breach-notification guidance.

Common questions from security buyers

Does Stoney store my source code? No. We process route definitions and diffs in flight during synthesis and PR analysis. We persist only the derived rules and the short diff excerpts that appear in forensic reports as evidence.

Can I self-host Stoney? Self-hosted deployment is available on the Enterprise plan. Contact sales@stoneydev.com.

Do you offer SSO? SAML / SSO (Okta, Azure AD, Google Workspace) ships with the Enterprise plan.

Is my Jira ticket data sent to Anthropic? Only ticket summaries and descriptions relevant to the route cluster currently being synthesized. Per Anthropic’s commercial terms, these inputs are not used to train models.

Can I delete everything? Yes. Settings → Account → Delete. Data is purged within 30 days; backups age out 7 days after that. The audit log is retained separately for 7 years to satisfy SOC 2 requirements — contact founder@stoneydev.com if you need accelerated audit-log deletion for GDPR reasons.

What happens if Stoney goes down during an audit period? The evidence bundle is generated from persisted data in the rule registry and drift history. As long as the underlying data exists, the bundle can be re-generated — service uptime during the export step is not a precondition for the evidence itself.

Where to go next

• Back to Getting started for the broader product overview
• Ownership and escalation for the operational side of how drift gets surfaced
• stoneydev.com/security for the security page itself, including the SOC 2 status and the responsible-disclosure policy