Compliance & Data Protection
Enterprise data storage and compliance
Data flow
Discord is the source of truth for Discord objects. BastionHub normalizes security metadata and stores it on AWS infrastructure. Owners access it through the authenticated portal.
Discord servers, members, roles, channels, and audit logs. Discord owns all Discord data. BastionHub never replicates message bodies, attachments, or credentials.
BastionHub reads Discord security signals via official Discord APIs, normalizes them into threat metadata, and enforces owner-defined policy. The browser never talks to Discord directly.
Normalized security metadata is stored in PostgreSQL hosted on AWS infrastructure. Encryption at rest and in transit is handled by the infrastructure provider.
Server owners access their tenant-scoped data through the authenticated Owner Dashboard. Every query is guild-isolated. Staff Dashboard access is role-mapped and restricted.
Infrastructure details
| Property | Value |
|---|---|
| Infrastructure provider | Amazon Web Services (AWS) |
| Database engine | PostgreSQL (managed via Supabase) |
| Primary region | US-West-2 (Oregon, USA) |
| EU region | Available on request (Enterprise) |
| Encryption in transit | TLS 1.2+ (enforced on all connections) |
| Encryption at rest | AES-256 (Supabase managed PostgreSQL on AWS) |
| Backups | Daily with PITR (Supabase Pro+ required for production) |
| Connection pooling | PgBouncer via Supabase pooler |
| Access control | Prisma service role (server-side only) + tenant isolation on every query |
| RLS | Defense-in-depth Row Level Security (planned for production) |
What BastionHub stores vs. does not store
✓ Stored
Discord guild IDs, names, and member counts
✓ Stored
Threat detection metadata (type, action, timestamp)
✓ Stored
Audit log entries (who, what, when, why)
✓ Stored
Owner-defined security policies and role mappings
✓ Stored
Exposure monitoring findings (breach name, severity, remediation)
✓ Stored
Billing entitlements and subscription status
✕ Never stored
Discord message bodies, embeds, or attachments
✕ Never stored
Passwords, password hashes, or seed phrases
✕ Never stored
Raw webhook tokens
✕ Never stored
DM content (except when a user messages the bot)
✕ Never stored
Data from other tenants
Subprocessors
BastionHub engages the following subprocessors to deliver the service. Each is a reputable, enterprise-grade provider. Customers can request notification of new subprocessors before they are engaged.
| Provider | Role | Location | DPA |
|---|---|---|---|
| Amazon Web Services (AWS) | Cloud infrastructure & data storage | US-West-2 (Oregon, USA) | Available via Supabase enterprise agreement |
| Supabase | Managed PostgreSQL (runs on AWS) | US-West-2 (Oregon, USA) | Available on Pro tier and above |
| Discord Inc. | Source of Discord data (official API & OAuth2) | USA | Discord Developer Terms of Service |
| Stripe | Payment processing (subscription billing) | USA | Stripe DPA available for merchants |
| Have I Been Pwned | Breach intelligence provider (exposure monitoring) | Australia | HIBP API terms of service |
| Vercel | Web application hosting (Next.js) | USA / Global edge | Vercel DPA available on Pro tier |
Compliance status
Data Processing Agreement (DPA)
A DPA is available for Pro and Enterprise customers. It defines BastionHub as a data processor, the customer as a data controller, and outlines subprocessor obligations.
Available
View DPACCPA / CPRA compliance
BastionHub does not sell personal information. Server owners can delete all tenant data from the Owner Dashboard. Data subjects can submit access, export, or deletion requests via the public form. CCPA disclosure is published in the Privacy Policy.
Implemented
Submit a data subject requestGDPR Right to Erasure
EU residents can request data deletion. Owners can wipe all BastionHub data for their server from Owner Dashboard Settings. Litigation hold may pause deletion when legally required.
Implemented
View GDPR noticeData residency (US vs EU)
Data is currently stored in AWS US-West-2 (Oregon). EU region hosting is available for Enterprise customers on request. Contact us before purchase if EU residency is required.
Partial
Contact about EU residencyEncryption (at rest + in transit)
All data is encrypted at rest with AES-256 (Supabase managed PostgreSQL on AWS). All connections use TLS 1.2+. Secrets are never stored in frontend bundles or committed to git.
Implemented
Content-Security-Policy (CSP)
All routes enforce a strict CSP header: scripts and styles from same origin only, no external frames, no external form submissions, no plugins. Prevents XSS and injection attacks.
Implemented
HSTS (Strict-Transport-Security)
In production, all responses include HSTS with 1-year max-age, includeSubDomains, and preload-ready. Forces HTTPS and prevents protocol downgrade attacks.
Implemented
Rate limiting
All API routes enforce rate limits: auth routes (10/min), mutation routes (20/min), read routes (60/min), webhooks (100/min). Rate limit violations are logged as security alerts.
Implemented
CSRF protection
All mutation endpoints verify same-origin via Origin and Referer headers. Cross-origin requests are blocked and logged as security alerts. Production requires explicit origin.
Implemented
Security headers
X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: no-referrer, Permissions-Policy (camera/mic/payment disabled), Cross-Origin policies, DNS prefetch disabled.
Implemented
Incident response plan
Documented 7-phase incident response plan: detect, assess, contain, notify (72hr GDPR), investigate, remediate, report. Includes credential rotation procedures and escalation contacts.
Implemented
View incident response planBreach detection (automated alerts)
Security events are automatically logged to the audit trail: rate limit violations, CSRF failures, tenant isolation violations, privilege escalation, invalid guild IDs, billing bypass attempts.
Implemented
Backups and PITR
Daily backups and point-in-time recovery require Supabase Pro tier or higher. This is enabled before onboarding paying enterprise customers. Currently in build phase on Free tier.
Planned
Key rotation
All credentials (AUTH_SECRET, Discord token, HIBP key, Stripe key, database password) should be rotated quarterly. The incident response plan documents rotation procedures. Currently manual — automated rotation is planned.
Planned
View rotation proceduresSOC 2 Type II
SOC 2 compliance is on the roadmap for Enterprise enterprise contracts. The security architecture (tenant isolation, audit logs, encryption, access control, rate limiting, CSP) is designed to meet SOC 2 controls.
Planned
Retention and purge
Basic retains threat metadata for 90 days. Pro supports up to 7 years of BastionHub threat metadata and audit evidence retention (not Discord message content). Live threat metadata retention is owner-configurable. Enterprise retention is contract-defined. Owners can adjust retention and activate litigation hold.
Implemented
Manage retentionAudit trail
Every significant action (view, export, delete, configure, verify) is written to an audit log with actor, timestamp, guild, and action type. Security alerts are also logged. Audit logs are exportable for SIEM integration.
Implemented
View audit trailMFA / 2FA
Internal operator access requires TOTP-based MFA. Owner Dashboard uses Discord OAuth2. Staff Dashboard access is role-mapped via stable Discord IDs.
Implemented
What BastionHub does NOT do
Honesty matters more than marketing. These are the things BastionHub explicitly does not do, and in most cases cannot do under Discord's Developer Terms and Developer Policy. If a competitor claims a capability on this list, ask how they achieve it within Discord's rules.
| Capability | BastionHub status | Why |
|---|---|---|
| Archive Discord message content | Not implemented | BastionHub stores threat metadata only (IDs, types, actions, hostnames, reason codes). Message bodies, embeds, and attachments are never persisted. Storing message content would require amending our Discord App Review submission to add a new stated use case and obtaining legal counsel on retention obligations. |
| Direct backend access to Discord | Not available | No such access exists. BastionHub uses the official Discord bot API and OAuth2 — the same API every bot developer uses. There is no special "Discord enterprise export gateway." |
| Bypass Discord deletion rules | Not permitted | BastionHub honors Discord's Developer Terms, which require prompt deletion of API Data on request (with a legal-compliance exception). We do not market or implement any bypass of Discord's deletion obligations. |
| Query customer S3/Azure directly | Not implemented (security choice) | BastionHub never stores customer cloud access keys. Exports are delivered to a customer-owned HTTPS collector that the customer controls. The customer writes to their own S3/Azure — BastionHub never touches the customer's cloud credentials. |
| Claim "court-admissible" exports | Not claimed | BastionHub exports are tamper-evident with SHA-256 hash chain and HMAC signature — integrity-grade, not a standalone claim of court admissibility. Court admissibility depends on jurisdiction, legal process, and trusted time anchoring (RFC 3161), which BastionHub does not provide. |
| Claim "zero knowledge" or "memory only" | Not claimed | BastionHub is a full data processor with access to plaintext metadata. "Zero knowledge" would require client-side encryption or customer-managed keys where BastionHub cannot decrypt — a future Phase 3 enhancement, not the current architecture. |
| Scrape or mine Discord data | Prohibited by Discord Policy | Discord's Developer Policy explicitly prohibits scraping, mining, profiling users, and using API Data outside stated functionality. BastionHub inspects messages in memory for detection and persists only non-content metadata. |
| Train AI models on Discord content | Prohibited by Discord Policy | Discord's Developer Policy (Item 21) prohibits using message content to train ML/AI models without express Discord permission. BastionHub does not train models on Discord data. |
| Read DMs (except when messaged) | Not implemented | BastionHub does not read or monitor DMs. The bot only processes messages in guild channels where it has been added with appropriate permissions. DM surveillance is not marketed. |
| Grant Administrator to members | Never | The bot requests Administrator once at install so no feature hits a permission wall. BastionHub never grants Administrator to members and never implies it outranks Discord or the server owner. |
| Four-eyes sign-off on exports | Planned (Phase 2) | Enterprise platforms like Smarsh and Global Relay offer four-eyes sign-off on sensitive exports. BastionHub's current architecture uses owner + MFA + step-up for destructive operations. Four-eyes is a future enhancement. |
| External timestamp anchoring (RFC 3161) | Planned (Phase 2) | BastionHub's hash chain proves integrity and order, but timestamps come from the host clock. External anchoring to a trusted timestamp authority or transparency log would fix the chain in time so an operator cannot silently rewrite history. This is a future enhancement. |
| SOC 2 Type II attestation | Roadmap | SOC 2 is a roadmap item for enterprise contracts. BastionHub has not completed a SOC 2 audit. Customers requiring SOC 2 should contact us for the current timeline. |
What BastionHub does do
These capabilities are implemented and available in the Owner Dashboard Compliance Center today.
- Compliance officer search — Search BastionHub threat metadata by user ID, threat type, regulatory tracking code, date range, data category, and legal-hold status.
- SHA-256 integrity verification — Each record includes a SHA-256 hash computed over its canonical JSON. Export bundles include a hash chain (linkn = H(recordn || linkn-1)) for tamper-evidence.
- Tamper-evident export bundles — JSON and CSV exports with hash chain, manifest SHA-256, and HMAC-SHA256 signature using a per-guild key derived from AUTH_SECRET. Verifiable offline by a third party.
- Per-record legal hold — Place or release a legal hold on individual threat-log records. The retention purge skips held records even if their retention period has expired. Independent of the guild-level litigation hold.
- Compliance audit trail — Every search, export, and legal hold action is logged with actor, timestamp, and action details. Separate from the owner/admin audit log.
- CCPA/GDPR deletion-request intake — Public form for data subjects (not just owners) to request access, export, or deletion of their data from BastionHub threat logs. Owners approve or deny via the portal.
- Regulatory tracking codes — Customer-assigned codes (e.g., "FINRA-4511-2024-Q3") on threat-log records for matter/case tracking.
- Data classification — Each record is categorized as THREAT_METADATA, AUDIT, CONFIG_SNAPSHOT, or CUSTOMER_EVIDENCE for per-category retention and search.
- Customer-owned HTTPS collector export — Exports are delivered to a customer-controlled HTTPS endpoint. BastionHub never stores cloud access keys. SSRF protection blocks private IPs, localhost, and metadata endpoints.
- Guild-level litigation hold — Pause all retention purges for a guild during active litigation. Per-record holds provide finer-grained control.
- Step-up MFA for destructive operations — Deletion, retention changes, and legal hold toggles require a recent TOTP step-up challenge, not just an enabled 2FA.
- Tenant isolation — Every query is guild-scoped. No cross-tenant data access. Cascade-delete on tenant removal.