We take protecting customer data seriously. This document describes the technical and organizational measures we use to safeguard the GovConHelp Service (the “Service”). It supplements our Privacy Policy and Terms of Service.
Security is a process, not a destination. If you find a vulnerability or have a question about our practices, contact [email protected]. Our target response times are:
This Policy applies to the production GovConHelp web application, its supporting infrastructure, the data we process on behalf of customers, and our staff handling of that data. It does not apply to customer-side controls (how you secure your own workstations, the strength of passwords you choose, etc.) or to third-party services we integrate with (see §12 Subprocessors).
CURRENT The Service runs in a containerized deployment on Digital Ocean, hosted in United States. Customer data is stored in a PostgreSQL database with daily snapshots retained for 30 days. Uploaded files (logos, RFP PDFs, generated DOCX exports) are stored in a dedicated volume served through an authenticated Django view; the volume is not directly internet-reachable.
CURRENT All HTTPS traffic terminates at a reverse proxy (Caddy) which automatically provisions and renews TLS certificates via Let's Encrypt. HTTP traffic is redirected to HTTPS.
CURRENT Administrative interfaces (Django admin, ops dashboards) are gated by a source-IP allowlist enforced at both the proxy layer and the Django middleware layer. Anything outside the allowlist receives a 404 (intentionally — to prevent path-fingerprinting).
CURRENT All traffic between your browser and the Service uses TLS 1.2 or higher. We do not accept unencrypted HTTP connections to authenticated routes.
CURRENT Sensitive credentials and integration secrets stored in the database (API keys for Anthropic, OpenAI, Stripe, SAM.gov, etc., webhook signing secrets, status-dashboard tokens) and the long-form customer-content columns (extracted RFP text, proposal section drafts, cost narratives, company tax IDs) are encrypted at the application layer using AES-256-GCM (authenticated encryption: 256-bit key, 96-bit per-write nonce, 128-bit authentication tag). The encryption key is stored as an environment secret separate from the database backups. Rows previously written under our Fernet scheme (AES-128-CBC + HMAC-SHA256) are read transparently and migrated to AES-256-GCM on the next maintenance pass; the legacy key is retired once every row has been re-encrypted.
CURRENT User passwords are stored as Django-format password hashes (PBKDF2-SHA256, default 600,000 iterations). We never store plaintext passwords. Password reset tokens are short-lived and single-use.
CURRENT Uploaded files are stored on encrypted block storage provided by our hosting vendor. Access requires authentication; the protected-media view enforces a per-request ownership check before bytes are streamed.
CURRENT Every customer-facing view that returns or mutates data filters the query by the requesting user's workspace owner. Cross-tenant access via direct URL probing returns a 404. This isolation is enforced in code at every view function, audited as part of our security-review process.
CURRENT Customer-facing URLs for Company and Proposal records use opaque 12-character identifiers ("public IDs") rather than sequential integers. This is information-disclosure defense — an outsider cannot probe /companies/<i>/ to estimate customer counts or growth velocity.
CURRENT Staff (employees with administrative access to the running system) are subject to:
CURRENT Incoming webhooks from Stripe are validated by signature comparison against the shared webhook secret. Unsigned or invalid requests are rejected before any state mutation. Webhook events are de-duplicated via a database-level lock to defeat replay attacks.
CURRENT Customers authenticate with email and password. Optional two-factor authentication via TOTP is available for customer accounts and recommended for any account that controls real proposal data.
CURRENT Sessions are secured with HttpOnly + Secure cookies. CSRF protection is enforced on every state-changing request. Sessions are bound to a single browser and are invalidated by password change, MFA enrollment, account deletion, or staff-initiated session purge.
CURRENT Team invites and email unsubscribe links use 64-character random tokens with adequate entropy (~384 bits). Tokens are stored only as SHA-256 digests; the cleartext token is never persisted server-side. Team invites expire after 14 days. Email unsubscribe operates POST-only (a GET renders a confirmation form) so prefetchers cannot accidentally unsubscribe a user.
CURRENT Portions of customer Workspace Content are transmitted to Anthropic (primary) and, when the circuit breaker trips or an operator manually toggles fallback, OpenAI (secondary). What we send for each task is described in the Privacy Policy §4.
CURRENT Both providers are accessed via paid API tiers. Per their respective commercial API terms in effect as of 17 May 2026, prompts and completions are not used to train models. We have not entered Zero-Retention agreements with either provider; standard abuse-monitoring retention applies. See:
CURRENT We log AI calls in our database with model name, token counts, estimated cost, duration, and success/error status. Prompt content and completion content are not stored in our system after the response is rendered to the customer.
ROADMAP Zero-retention or HIPAA-eligible AI-provider configurations for customers with elevated compliance requirements. Contact us if this is required for your contract.
CURRENT Customer data retention windows:
| Data class | Retention |
|---|---|
| Active Account & Workspace Content | Until you delete |
| Soft-deleted records (companies, proposals) | 30 days, then permanent purge |
| Account deletion | Personal data removed within 30 days of request |
| Audit log | 365 days |
| Server logs | 90 days |
| AI usage records (metering rows: model, token counts, cost, timestamp — no prompt or response payload) | Retained for billing reconciliation and aggregate analytics |
| Backups | Daily snapshots retained for 30 days |
You may request deletion of your data via the in-app account-deletion flow at /profile/delete/ or by emailing [email protected].
CURRENT The database is backed up by our hosting provider via automated daily snapshots, retained for 30 days. Uploaded files are backed up on the same cadence.
ROADMAP Documented quarterly disaster-recovery drills with measured RTO/RPO targets. Until established, our published recovery objectives are:
CURRENT Application errors are captured to server-side logs; sensitive fields (passwords, tokens, encrypted secrets) are scrubbed before any log entry is written.
CURRENT Operational dashboards expose worker health, queue depth, recent failures, and AI fallback usage to staff. A status endpoint (/status/) responds with health and degradation indicators; detailed status is restricted to staff sessions and to monitors carrying a short-lived signed token.
ROADMAP Independent log aggregation with tamper-evident retention. Currently logs reside on the application host.
CURRENT Dependencies are pinned via lockfile and updated periodically. Critical CVEs in customer-facing dependencies are evaluated within 14 business days and patched on a risk-prioritized basis.
CURRENT Source code changes are reviewed before merging to the production branch. Authorization-sensitive code paths receive additional review focused on workspace-scoping correctness.
ROADMAP Annual third-party penetration testing and a published bug-bounty program. Until established, we welcome and reward responsibly-disclosed reports through the channel in §13.
CURRENT Our incident response process:
We use the following third-party services to operate the Service. Each operates under its own security and compliance posture. See the Privacy Policy §5 for the full list and the data shared with each.
| Subprocessor | Function | Published certifications |
|---|---|---|
| Digital Ocean | Cloud hosting | SOC 2 Type II, ISO 27001 |
| Anthropic, PBC | AI inference (primary) | SOC 2 Type II (per Anthropic) |
| OpenAI, LLC | AI inference (fallback) | SOC 2 Type II (per OpenAI) |
| Stripe, Inc. | Payment processing | PCI DSS Level 1, SOC 1/2 |
| Resend | Transactional email | SOC 2 Type II |
| SAM.gov (U.S. GSA) | Federal entity / opportunity data lookups | Federal government system |
We update this page when we add a new subprocessor that processes customer Workspace Content. Customers who want explicit notification of subprocessor changes may subscribe to our security mailing list by emailing [email protected] with the subject “subprocessor notifications.”
If you find a vulnerability, security weakness, or data exposure:
For all other security inquiries (including customer assessments, SOC 2 status updates, subprocessor change history, or DPA execution), email [email protected].