A real sample security pack

Driftnet — Security & Trust

Based on answers provided by Driftnet on 2026-06-11. Self-attested by the vendor; not audited or certified by any third party.

Overview

Driftnet is an LLM-eval tool that catches output drift, built for solo developers. The company is a one-person operation; the founder is the sole engineer, administrator, and security contact. Security controls reflect that scale: direct, hands-on, and limited to what a single operator can maintain reliably.

Infrastructure & Hosting

Driftnet runs on Vercel serverless functions and Vercel Blob storage. All customer data resides in the United States, Vercel region iad1. Order and eval records in Vercel Blob are covered by automated daily snapshots retained for 30 days. A public status page is available at status.forage.bot.

Data Protection

Data stored: Customer email addresses, eval prompts and model outputs submitted for testing, and billing records processed through Stripe.

Encryption in transit: TLS 1.2 or higher on all endpoints.

Encryption at rest: Provider-managed encryption on Vercel Blob storage.

Retention and deletion: Data is deleted from live systems within 30 days of a written deletion request sent to driftnet@forage.bot.

Export: Customers can download their eval results as JSON directly from the dashboard at any time.

GDPR: Export and deletion requests for data subjects are handled on request via driftnet@forage.bot.

Access & Authentication

Production systems and customer data are accessible only to the founder. Access is protected by individual credentials with two-factor authentication (2FA) enforced on all critical systems. The founder's machines use full-disk encryption and OS automatic updates.

No third-party staff, contractors, or support agents have access to production data.

Incident Response & Breach Notification

The founder monitors systems via alerts and application logs. Upon detecting an incident, the process is: assess scope, apply a fix, and notify affected customers by email. Affected customers will be notified within 72 hours of confirming a security incident. Application and infrastructure logs are retained for 90 days to support investigation.

Monitoring & Vulnerability Management

Dependency alerts are handled through GitHub Dependabot. Critical patches are applied within days of notification. Application and infrastructure logs are retained for 90 days.

Development practices include: staging preview deployments before any production deploy, secrets stored in environment configuration rather than source code, and an automated test suite run on every change.

Subprocessors

The following third parties process or have access to customer data:

| Subprocessor | Purpose | |---|---| | Vercel | Hosting, serverless compute, and Blob storage | | Stripe | Payment processing and billing records | | OpenRouter | LLM inference for eval execution | | GitHub | Support issue tracking |

Current Posture & Roadmap

In place today

• TLS 1.2+ encryption in transit on all endpoints
• Provider-managed encryption at rest on Vercel Blob
• Automated daily snapshots retained 30 days
• 2FA enforced on all critical systems for the founder
• Full-disk encryption and OS auto-updates on staff devices
• GitHub Dependabot for automated dependency alerts; critical patches applied within days
• Application and infrastructure logs retained 90 days
• Staging previews before production deploys; secrets in environment config, not source
• Automated test suite on every change
• Data deletion within 30 days on written request
• GDPR export and deletion handled on request
• Customer breach notification within 72 hours of confirmed incident
• Public status page at status.forage.bot

Planned

• We plan to introduce a documented disaster-recovery runbook.
• We plan to offer SSO to customers.
• We plan to commission a third-party penetration test.
• We plan to pursue a security certification (such as SOC 2 or ISO 27001).
• We plan to obtain cyber-liability insurance.

Contact

Security questions, vulnerability disclosures, and data-subject requests (including GDPR export or deletion) should be directed to:

[driftnet@forage.bot](mailto:driftnet@forage.bot)

Responses are handled directly by the founder. There is no ticketing intermediary for security matters.

Security Questionnaire Answer Bank — Driftnet

Based on answers provided by Driftnet on 2026-06-11. Self-attested by the vendor; not audited or certified by any third party.

Q: How is customer data encrypted at rest?

A: Customer data stored in Vercel Blob storage is protected by provider-managed encryption at rest. This covers all data categories we hold: customer email addresses, eval prompts and model outputs, and billing records managed via Stripe. We rely on Vercel's built-in encryption controls for the underlying storage layer rather than a separate key-management system of our own.

Q: How is customer data encrypted in transit?

A: All endpoints served by Driftnet enforce TLS 1.2 or higher; no unencrypted HTTP connections are accepted for data transmission. This applies to traffic between end users and our Vercel-hosted serverless functions as well as data flows to our subprocessors. There are no carve-outs for internal or administrative traffic.

Q: How do you control access to production systems and customer data, and how is least-privilege applied?

A: Production access is limited to the sole founder; no shared or service accounts with broad permissions exist. Access to Vercel infrastructure and customer data is authenticated via individual credentials protected by two-factor authentication. Because the team consists of one person, there is no access-provisioning or de-provisioning workflow to manage, and no third-party staff or contractors hold access to production systems.

Q: Is multi-factor authentication (MFA) enforced for staff accessing critical systems?

A: Yes. Two-factor authentication is enforced on all critical system accounts used by the founder, including access to Vercel, GitHub, and Stripe. There is one staff member in total, so MFA coverage is 100% of the team. No administrative access to production systems is possible without completing the second factor.

Q: How are backups handled, and do you have a disaster-recovery plan?

A: Order and eval records stored in Vercel Blob are covered by automated daily snapshots retained for 30 days, allowing point-in-time recovery within that window. The public status page at status.forage.bot reflects current service availability. A documented disaster-recovery runbook does not yet exist; this is a planned item on our roadmap and we intend to produce one as operational complexity grows.

Q: What is your incident-response process, and what is your breach-notification commitment?

A: Incidents are detected via monitoring alerts, assessed for scope and impact by the founder, remediated, and followed by direct email notification to affected customers. Our committed notification window is within 72 hours of confirming that an incident has occurred. This process is founder-run given the team size of one; there is no dedicated security-operations function. Security disclosures can be sent to driftnet@forage.bot at any time.

Q: Which subprocessors handle or have access to customer data?

A: Four subprocessors touch customer data: Vercel (serverless compute and blob storage, United States — iad1 region), Stripe (payment processing and billing records), OpenRouter (LLM inference for eval runs), and GitHub (support issue tracking). Customer eval prompts and model outputs submitted for testing are processed through OpenRouter as part of the core product function. We maintain this list and will notify customers of material changes to it.

Q: How can customers request data deletion, and what are your data-retention practices?

A: Customers may request deletion of their data by emailing driftnet@forage.bot; data is removed from live systems within 30 days of a confirmed request. We store customer email addresses, eval prompts and model outputs, and billing records via Stripe — no additional personal data categories are collected. GDPR data-subject requests for both export and deletion are handled through the same support email channel.

Q: How do you manage software vulnerabilities and dependency updates?

A: GitHub Dependabot is enabled on the codebase and generates automated alerts when dependencies have known vulnerabilities. Critical patches are applied within days of an alert being raised. All changes pass through an automated test suite and are deployed via staging preview environments before reaching production, reducing the risk of a vulnerability fix introducing a regression.

Q: Do you support SSO (SAML, OIDC) for customer authentication?

A: SSO for customers is not currently available. Driftnet is built for solo developers and the existing authentication model reflects that. SSO support is on our roadmap as a planned capability; we do not have a committed delivery date at this time.

Q: What security certifications do you hold (e.g., SOC 2, ISO 27001)?

A: Driftnet does not currently hold any third-party security certifications such as SOC 2 or ISO 27001. The controls described in this document are self-attested. What is in place today includes TLS 1.2+ encryption in transit, provider-managed encryption at rest, MFA-only production access, automated dependency alerting, 90-day audit log retention, and a documented 72-hour breach-notification commitment. Pursuing formal certification is on our roadmap; we have not yet begun that process.

Q: Do you maintain audit or access logs, and how long are they retained?

A: Application and infrastructure logs are retained for 90 days. These logs cover activity on the Vercel-hosted serverless functions and associated infrastructure. Because all production access is limited to a single individual using individually credentialed, MFA-protected accounts, the log surface for access auditing is narrow and attributable. Logs are available for review in the event of an incident or customer inquiry.

Access Control & Identity Policy

Based on answers provided by Driftnet on 2026-06-11. Self-attested by the vendor; not audited or certified by any third party.

Scope

This policy covers how access to Driftnet's production systems, customer data, and supporting infrastructure is granted, managed, and revoked. It applies to all systems involved in delivering the Driftnet service at driftnet.forage.bot, including Vercel (hosting and blob storage), Stripe (billing), OpenRouter (LLM inference), and GitHub (support issue tracking).

Account Provisioning and Deprovisioning

Driftnet is operated by a single founder. There are no employees, contractors, or additional staff accounts to provision or deprovision at this time. Any future addition of personnel would require a review of this policy before access is granted.

Customer accounts are created through the Driftnet application directly. When a customer requests deletion of their data, we remove it from live systems within 30 days of receiving the request via support email at driftnet@forage.bot. Account closure and data deletion are treated as a single workflow.

Production Access

Access to production systems and customer data is restricted to the founder only. No shared or service accounts with broad production access exist. Access to Vercel, Stripe, OpenRouter, and GitHub is managed through individual credentials held solely by the founder — not shared credentials or team tokens.

Customer data stored in Vercel Blob — including email addresses, eval prompts, model outputs, and billing records managed via Stripe — is accessible only through authenticated, privileged access to the relevant provider consoles or through application-layer queries that enforce authentication.

Authentication Requirements

Staff

Two-factor authentication (2FA) is enforced on all critical system accounts used by the founder, including access to Vercel, Stripe, GitHub, and OpenRouter. No production system access is permitted without 2FA.

The founder's machines use full-disk encryption and are configured to apply OS updates automatically, reducing the risk of credential exposure through a compromised endpoint.

Customers

Customers authenticate to the Driftnet dashboard using application-level credentials. Eval results are available for export as JSON from within the authenticated dashboard session.

Least Privilege

Because the team consists of one person, the practical scope of access is narrow by design: only one set of credentials exists, and those credentials are scoped to the services Driftnet actually uses. We do not create additional roles or service accounts with broader access than needed for a given integration. Secrets and API keys are stored in environment configuration on Vercel, not in source code or version control.

Application and infrastructure logs are retained for 90 days, allowing review of access patterns and events without requiring standing access to raw data stores.

Roadmap

The following items are not yet in place but are planned for future implementation:

• Customer SSO: We plan to offer SSO to customers. This is not currently available; customers authenticate using application-level credentials only.
• Third-party penetration test: We plan to engage a third party to conduct a penetration test of Driftnet's systems. No external penetration test has been performed to date.
• Security certifications: We plan to pursue formal security certifications. Driftnet currently holds no security certifications such as SOC 2 or ISO 27001.

Questions about this policy or access-related security concerns can be directed to driftnet@forage.bot.

Incident Response & Breach Notification Policy

Based on answers provided by Driftnet on 2026-06-11. Self-attested by the vendor; not audited or certified by any third party.

Overview

Driftnet is a one-person operation hosted on Vercel, serving solo developers who use our LLM-eval tooling. Because the team has a single member — the founder — our incident response process is direct and personal rather than delegated across a team. This document describes how we detect, assess, contain, and communicate security incidents, and what customers can expect from us if something goes wrong.

Detection

We detect incidents primarily through application and infrastructure logs retained for 90 days on Vercel, combined with automated monitoring and alerting. Automated dependency alerts via GitHub Dependabot flag known vulnerabilities in our software supply chain. When an alert fires or an anomaly surfaces in logs, the founder reviews it directly. Customers and security researchers can also report concerns at any time by emailing driftnet@forage.bot.

Assessment

Once a potential incident is identified, the founder assesses it to determine:

• Scope — which systems or data categories are involved (customer email addresses, eval prompts and model outputs, or billing records via Stripe)
• Severity — whether access to production data has occurred or whether the issue is contained to infrastructure configuration
• Affected parties — which customer accounts, if any, are implicated based on the available logs

Because production access is limited to the founder alone, authenticated via individual credentials with 2FA, the population of people who could cause or escalate an incident from the inside is small by design.

Containment & Remediation

Containment steps depend on the nature of the incident but generally follow this sequence:

1. Isolate or disable the affected component (e.g., revoke credentials, take down a misconfigured endpoint, roll back a deploy)
2. Apply fixes — for dependency vulnerabilities, critical patches are applied within days of confirmation
3. Verify that the fix is effective before restoring full service
4. Deploy through staging previews before returning to production, consistent with our standard development practice

Secrets are held in environment configuration, not in source code, which limits the blast radius of a repository-level exposure.

Customer Notification

If we confirm a security incident that affects customer data, we will notify all affected customers by email within 72 hours of confirming the incident. Notifications will describe what happened, what data was involved, what we did to contain it, and any steps customers should take. We send notifications to the email address associated with each affected account.

For ongoing status during and after an incident, customers can check our public status page at status.forage.bot.

Post-Incident Review

After containment and customer notification, the founder conducts a review covering:

• Root cause and how the incident was introduced or enabled
• Whether detection was timely and what, if anything, would have surfaced it sooner
• Changes to configuration, code, or process that reduce the likelihood of recurrence
• Whether the 72-hour notification window was met, and if not, why

Findings are documented for internal reference and inform future development and operational decisions.

Roadmap

The following recovery-related items are not yet in place. We plan to address them as the product and team grow:

• Documented disaster-recovery runbook — We plan to create a formal DR runbook covering data restoration from Vercel Blob daily snapshots and recovery time targets.
• Third-party penetration test — We plan to engage an external firm to conduct a penetration test of Driftnet's endpoints and infrastructure.

We will update this document as these items are completed.

Data Protection & Retention Policy

Based on answers provided by Driftnet on 2026-06-11. Self-attested by the vendor; not audited or certified by any third party.

Overview

Driftnet is a single-operator LLM-eval tool hosted at driftnet.forage.bot. This document describes the data we collect, how we protect and retain it, and the rights customers have over it. Security questions and disclosure reports should be sent to driftnet@forage.bot.

Data Categories We Handle

We store three categories of customer data:

• Account data: Customer email addresses used for authentication and communications.
• Eval data: Prompts and model outputs submitted by customers for drift testing.
• Billing records: Payment metadata processed through Stripe. We do not store raw card numbers; Stripe handles payment-card data directly.

Encryption

In transit: All data transmitted between customers and Driftnet endpoints is protected using TLS 1.2 or higher. This applies to the dashboard, API endpoints, and any data sent to or returned from subprocessors over our connections.

At rest: Customer data stored in Vercel Blob storage is encrypted at rest using provider-managed encryption. We do not manage encryption keys directly; Vercel applies encryption across all objects in Blob storage.

Backups and Retention

Order and eval records stored in Vercel Blob are covered by automated daily snapshots. Snapshots are retained for 30 days, after which they are automatically removed. Application and infrastructure logs are retained for 90 days.

We do not retain customer data beyond what is needed to operate the service. Live customer data is removed from production systems within 30 days of a verified deletion request (see below).

Data Deletion and Export

Deletion: Customers may request deletion of their data at any time by emailing driftnet@forage.bot. We will remove the data from live systems within 30 days of confirming the request.

Export: Customers can download their eval results at any time as JSON directly from the dashboard. No special request is required for export.

Subprocessors

The following third parties process customer data on our behalf:

| Subprocessor | Purpose | Data Touched | |---|---|---| | Vercel | Hosting, serverless compute, and Blob storage | All stored customer data; hosted in the United States (iad1 region) | | Stripe | Payment processing | Billing records and payment metadata | | OpenRouter | LLM inference routing | Eval prompts and model outputs during inference requests | | GitHub | Support issue tracking | Content of support communications |

All customer data at rest resides in the United States in Vercel's iad1 region.

GDPR Data-Subject Requests

We handle GDPR data-subject requests on an individual basis. Customers may request:

• Access / export: We will provide eval results and account data in JSON format.
• Deletion / erasure: We will remove data from live systems within 30 days of confirming the request.

Requests should be submitted by email to driftnet@forage.bot. We handle these requests manually given our team size of one.

Roadmap

The following items are not yet in place and are planned for future implementation:

• Documented disaster-recovery runbook: We plan to produce and publish a formal DR runbook covering data-restoration procedures from Vercel Blob snapshots.
• Customer SSO: We plan to offer SSO login options for customers who require it.
• Third-party penetration test: We plan to commission an external penetration test to validate our controls.
• Security certifications: We plan to pursue formal security certification (e.g., SOC 2) as the business grows.
• Cyber-liability insurance: We plan to obtain cyber-liability insurance coverage.