GOESRED INC

Security

Last updated October 17, 2026

GOESRED INC (“GoesRed”) builds administrative deadline tracking and reminder software for owner-operated bookkeeping and accounting practices. We treat security not as an afterthought, but as an architectural design constraint. This document provides a transparent overview of our technical, operational, and organizational security controls for our customers, partner platforms, and insurance underwriters.

1. Security by Design: Eliminating High-Risk Data

The most effective way to protect sensitive client data is not to possess it in the first place. GoesRed is engineered specifically to eliminate high-risk financial and identity vectors:

• No Taxpayer Identifiers: We do not collect, process, or store Social Security Numbers (SSNs), Individual Taxpayer Identification Numbers (ITINs), or Employer Identification Numbers (EINs). Our file ingestion pipeline programmatically parses uploaded spreadsheets and automatically rejects any workbook containing tax ID headers or nine-digit tax identifier formats.
• No Financial Account or Payroll Data: We never collect, process, or store bank account numbers, routing codes, general ledger transactions, or payroll wage records.
• No Payment Card Storage: Payment processing is handled exclusively through Stripe (a certified PCI-DSS Level 1 Service Provider). Payment card numbers never touch or transit GoesRed application servers.
• Optional, Isolated Client Phone Numbers: Client phone numbers are strictly optional, are never metered, are never sent to Meta or advertising networks, are never logged in application error trackers, and are never routed into an automated SMS pipeline.
• Advertising Attribution Isolation: Telemetry transmitted to Meta is restricted exclusively to first-party subscription acquisition attribution for the Bookkeeper’s own base membership purchase (incorporating hashed work email and request IP for geolocation under Meta Limited Data Use rules where applicable). Client roster entries, client emails, phone numbers, and tax identifiers are never shared with advertising platforms.

2. Multi-Tenant Logical Isolation (Database RLS)

GoesRed is architected with strict multi-tenant boundary enforcement. Application data resides in managed PostgreSQL databases featuring native Row Level Security (RLS) policies enforced directly at the database engine layer:

• Every database query executes within an authenticated tenant context bound to the bookkeeping firm’s unique identifier (firm_id).
• Direct tenant data cross-contamination is programmatically impossible at the database layer, ensuring complete tenant separation even in the event of application-level logic errors.
• Service-role keys and administrative credentials are restricted strictly to secure, isolated background workers and are never exposed to browser or client environments.

3. Encryption Standards

Encryption in Transit: All communications between customers, clients, and GoesRed services are encrypted using Transport Layer Security (TLS 1.3 and TLS 1.2). We enforce HTTP Strict Transport Security (HSTS) with preloading across all domain endpoints, ensuring modern browsers never establish unencrypted HTTP connections.

Encryption at Rest: All application databases, automated snapshot backups, and persistent storage volumes are encrypted at rest using industry-standard AES-256 cryptographic algorithms managed through AWS Key Management Service (KMS).

Browser Defense-in-Depth: Our web applications enforce modern browser defense-in-depth policies, including strict origin framing and MIME-type restrictions, to protect users against cross-site scripting and unauthorized framing.

4. Passwordless Authentication and Access Control

Traditional static passwords represent one of the most common vectors for credential stuffing, credential reuse, and account takeover attacks. GoesRed eliminates passwords entirely:

• Cryptographic Magic Links: Authentication relies on cryptographically random, single-use, time-limited (24-hour expiration) magic link tokens delivered directly to the verified business email on file.
• Google OAuth 2.0: Secure federated authentication is available via Google Identity Services, leveraging Google’s advanced security and multi-factor protections.
• Telecommunications OTP: Firm profile mobile numbers require two-way cryptographic verification via one-time passcodes (OTP) before mobile dispatch features can be enabled.
• Automated Bot Mitigation: Cloudflare Turnstile is embedded across all public entry points to block automated credential stuffing, brute force attempts, and scraping without invasive user friction.

5. Communication and Email Isolation

Dedicated Email Infrastructure: Outbound transactional deadline reminder emails to clients are routed through Postmark with dedicated email server isolation per firm. This design prevents sender reputation cross-contamination between accounting practices and ensures strict tenant communication isolation.

Cryptographic Inbound Verification: All inbound telecommunications and third-party webhook integrations require cryptographic authenticity verification before processing, preventing unauthorized spoofing or message injection.

Hard-Locked SMS Architecture: GoesRed server infrastructure has no technical capability or API integration to transmit automated SMS messages to bookkeepers’ clients. Client follow-up links utilize standard operating system sms: protocols that generate drafts on the bookkeeper’s local device, preserving human-in-the-loop verification and preventing unauthorized transmissions.

6. Cloud Infrastructure and Host Security

GoesRed application services run on tier-1 cloud infrastructure providers maintaining rigorous independent certifications, including SOC 2 Type II, ISO/IEC 27001, and PCI-DSS:

• Hosting Providers: Application edge and API layers run on Vercel and Railway, with database infrastructure provisioned on AWS via Supabase.
• DDoS Protection: Automated network-edge DDoS protection, rate limiting, and web application firewall (WAF) filtering are continuously active.
• Environment Separation: Staging (goesred-dev) and production (goesred) environments utilize strictly isolated databases, distinct API credentials, and separated third-party provider accounts.

Vendor Risk Management: We evaluate all third-party subprocessors (including Supabase, Stripe, Postmark, Telnyx, and Vercel) for SOC 2 Type II compliance, encryption standards, and strict adherence to data processing agreements (DPAs).

7. Monitoring, Audit Trails, and Logging Hygiene

PII-Sanitized Error Monitoring: We utilize Sentry for server-side error tracking. Sentry configurations enforce automated data scrubbing to ensure sensitive payloads, phone numbers, authorization headers, and cookie data are sanitized before telemetry is transmitted.

Immutable Audit Logs: Security-relevant events—including payment confirmations, magic link generation and consumption, user authentications, roster saves, and deadline clearance actions—are recorded to an immutable audit trail for governance, compliance verification, and dispute defense.

8. Vulnerability Management and Reporting

We continuously inspect our dependencies for vulnerabilities using automated static analysis and security tooling. We welcome responsible security disclosures from researchers, partners, and customers.

Vulnerability Reporting: If you believe you have identified a potential security vulnerability in a GoesRed service, please contact our security team immediately at security@goesred.com. We commit to acknowledging verified reports within 48 business hours and will not pursue legal action against researchers acting in good faith according to responsible disclosure standards.

Incident Response and Underwriting Governance: In the event of a confirmed security incident or data breach impacting customer data, GoesRed maintains a documented Information Security Incident Response & Data Breach Management Plan to isolate the threat, preserve forensic log integrity, conduct digital forensic root-cause analysis, and notify affected customers without unreasonable delay in accordance with state and federal statutory requirements.

9. Content Moderation, Takedown Procedures, and Media Compliance

To maintain media compliance, prevent trademark or copyright infringement, and satisfy Tech E&O insurance underwriting governance, GoesRed enforces a dual-track content moderation and pre-publication review standard:

• First-Party Material Pre-Publication Clearance: All public marketing copy, website pages, advertising creative, video integrations, and automated transactional reminder templates undergo mandatory executive officer review prior to public release to verify intellectual property licensing, factual accuracy, absence of defamatory claims, and compliance with statutory regulatory disclaimers.
• Administrative Input Restrictions: GoesRed is a closed B2B workflow platform with no public social networking, blogs, public user profiles, or open user-generated content forums. User input is strictly limited to administrative client roster fields (business names, contact names, and email addresses).
• Formal Takedown and Removal Protocol: We maintain a documented Standard Operating Procedure (SOP) for investigating and removing controversial, offensive, or allegedly infringing or defamatory materials. Third-party notices submitted to support@goesred.com are logged within 24 hours, evaluated by legal/security officers, and resolved with appropriate suspension or database purge within forty-eight (48) business hours.