legal

Data Security

Encryption, compliance, and data handling

7 min read
Updated 2026-02-24

Data Security & Compliance

๐Ÿ” Overview

This document provides detailed information about how OpsCurb secures your data and maintains compliance with industry standards.

Data Classification

We classify data into three categories:

1. Highly Sensitive ๐Ÿ”ด

  • User passwords (hashed with bcrypt)
  • Payment information (handled by Stripe, not stored by us)
  • API keys and tokens
  • External IDs

Protection: Encrypted at rest and in transit, access logged, MFA required

2. Sensitive ๐ŸŸก

  • AWS Account IDs
  • IAM Role ARNs
  • Scan results and findings
  • Cost data
  • Email addresses

Protection: Encrypted at rest and in transit, row-level security

3. Public ๐ŸŸข

  • Documentation
  • Marketing materials
  • Public API schemas

Protection: Standard security measures

Encryption

At Rest

  • Database: AES-256 encryption via Supabase (PostgreSQL)
  • File Storage: AES-256 encryption via AWS S3
  • Backups: Encrypted with separate keys
  • Key Management: AWS KMS for key rotation

In Transit

  • TLS 1.3: All API and web traffic
  • Certificate Pinning: Mobile apps (future)
  • HSTS: HTTP Strict Transport Security enabled
  • Perfect Forward Secrecy: Ephemeral key exchange

Key Management

  • Rotation: Keys rotated every 90 days
  • Separation: Different keys for different data types
  • Access: Keys accessible only to authorized services
  • Backup: Secure key backup and recovery process

Authentication & Authorization

User Authentication

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚   User      โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”˜
       โ”‚ 1. Login (email + password)
       โ–ผ
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚  Supabase Auth  โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
       โ”‚ 2. Verify credentials
       โ”‚ 3. Generate JWT token
       โ–ผ
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚   Application   โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
       โ”‚ 4. Validate token on each request
       โ–ผ
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚    Database     โ”‚ (RLS enforced)
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

Multi-Factor Authentication (MFA)

  • TOTP: Time-based one-time passwords (Google Authenticator, Authy)
  • SMS: SMS-based codes (optional)
  • Backup Codes: One-time recovery codes
  • Enforcement: Required for admin users, optional for others

Session Management

  • Token Expiry: 1 hour for access tokens, 30 days for refresh tokens
  • Refresh: Automatic token refresh
  • Revocation: Immediate token revocation on logout
  • Device Tracking: Track active sessions per device

Row-Level Security (RLS)

Every database query is automatically filtered by customer_id:

-- Example: Users can only see their own scans
CREATE POLICY "Users can view own scans"
ON scans FOR SELECT
USING (customer_id = auth.uid());

This is enforced at the database level, so even if application code has a bug, data remains isolated.

AWS Security

Cross-Account Access

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚  Your AWS Accountโ”‚
โ”‚                  โ”‚
โ”‚  โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”  โ”‚
โ”‚  โ”‚ IAM Role   โ”‚  โ”‚ โ† You create this
โ”‚  โ”‚ (Read-Only)โ”‚  โ”‚
โ”‚  โ””โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”˜  โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ผโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
         โ”‚
         โ”‚ AssumeRole with External ID
         โ”‚
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ–ผโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚ OpsCurb โ”‚
โ”‚                  โ”‚
โ”‚  โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”  โ”‚
โ”‚  โ”‚  Scanner   โ”‚  โ”‚ โ† We assume the role
โ”‚  โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜  โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

External ID Protection

  • Unique per customer: Each customer has a unique External ID
  • Prevents confused deputy: Protects against cross-account attacks
  • Rotation: Can be rotated without service interruption
  • Generation: Cryptographically secure random generation
# How we generate External IDs
import secrets
external_id = secrets.token_urlsafe(32)  # 256 bits of entropy

IAM Permissions Audit

We regularly audit our IAM permissions to ensure:

  • โœ… Only read-only permissions
  • โœ… No wildcard actions (except Describe*)
  • โœ… No resource-level write access
  • โœ… No access to sensitive data (S3 objects, database contents)

See terraform/main.tf for the complete IAM policy.

Infrastructure Security

Network Architecture

Internet
   โ”‚
   โ–ผ
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚   CloudFlare    โ”‚ โ† DDoS protection, WAF
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
         โ”‚
         โ–ผ
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚  Vercel (CDN)   โ”‚ โ† Frontend hosting
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
         โ”‚
         โ–ผ
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚  Railway.app    โ”‚ โ† API hosting
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
         โ”‚
         โ–ผ
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚   Supabase      โ”‚ โ† Database (private network)
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

API Security

  • Rate Limiting: 1000 req/hour (Free), 10,000 req/hour (Paid)
  • DDoS Protection: CloudFlare protection
  • WAF: Web Application Firewall rules
  • Input Validation: All inputs validated and sanitized
  • CORS: Strict CORS policies
  • CSRF: CSRF token protection

Monitoring & Logging

  • Application Logs: Structured logging with Sentry
  • Access Logs: All API requests logged
  • Audit Logs: Admin actions logged
  • Security Events: Failed logins, permission changes
  • Retention: 1 year for security logs

Vulnerability Management

  • Dependency Scanning: Automated with Dependabot
  • SAST: Static Application Security Testing
  • DAST: Dynamic Application Security Testing (planned)
  • Penetration Testing: Annual third-party testing
  • Bug Bounty: Responsible disclosure program

Compliance

Current Status

StandardStatusDetails
GDPRโœ… CompliantEU data protection
CCPAโœ… CompliantCalifornia privacy
SOC 2 Type II๐Ÿ”„ In ProgressExpected Q3 2026
ISO 27001๐Ÿ“‹ PlannedExpected Q4 2026
HIPAAโŒ Not ApplicableNo healthcare data
PCI DSSโœ… CompliantVia Stripe

GDPR Compliance

  • Data Minimization: We only collect necessary data
  • Purpose Limitation: Data used only for stated purposes
  • Storage Limitation: Data deleted after retention period
  • Data Portability: Export your data anytime
  • Right to Erasure: Delete your data anytime
  • Privacy by Design: Security built into every feature

CCPA Compliance

  • Transparency: Clear disclosure of data collection
  • Access Rights: View all data we have about you
  • Deletion Rights: Request data deletion
  • Opt-Out: Opt-out of data sale (we don't sell data)
  • Non-Discrimination: No penalties for exercising rights

AWS Well-Architected Framework

We follow AWS's 6 pillars:

  1. Operational Excellence: Automated deployments, monitoring
  2. Security: Encryption, IAM, least privilege
  3. Reliability: Multi-AZ, backups, disaster recovery
  4. Performance Efficiency: Serverless, auto-scaling
  5. Cost Optimization: Right-sized resources
  6. Sustainability: Efficient resource usage

Data Backup & Recovery

Backup Strategy

  • Frequency: Daily automated backups
  • Retention: 30 days
  • Encryption: AES-256 encrypted backups
  • Testing: Monthly restore testing
  • Geographic: Multi-region backup storage

Disaster Recovery

  • RTO (Recovery Time Objective): 4 hours
  • RPO (Recovery Point Objective): 24 hours
  • Failover: Automated failover to backup region
  • Testing: Quarterly DR drills

Data Retention

Data TypeRetentionReason
Scan Results90 days (Free), 1 year (Paid)Historical analysis
Account DataUntil deletionService provision
Audit Logs1 yearSecurity compliance
Backups30 daysDisaster recovery
Deleted Data30 days (soft delete)Recovery window

Incident Response

Security Incident Process

  1. Detection (0-1 hour): Automated alerts, monitoring
  2. Assessment (1-4 hours): Severity evaluation
  3. Containment (4-8 hours): Limit impact
  4. Notification (8-24 hours): Customer notification
  5. Eradication (24-48 hours): Remove threat
  6. Recovery (48-72 hours): Restore normal operations
  7. Post-Mortem (1 week): Root cause analysis

Customer Notification

We'll notify you within 24 hours if:

  • Your data was accessed by unauthorized parties
  • A security breach affects your account
  • We detect suspicious activity on your account

Incident Response Team

  • Security Lead: Coordinates response
  • Engineering: Technical investigation
  • Legal: Compliance and notification
  • Communications: Customer updates

Third-Party Security

Vendor Assessment

All third-party vendors are assessed for:

  • Security certifications (SOC 2, ISO 27001)
  • Data handling practices
  • Incident response capabilities
  • Compliance with regulations

Current Vendors

VendorPurposeCertifications
SupabaseDatabase & AuthSOC 2 Type II, ISO 27001
Railway.appAPI HostingSOC 2 Type II
VercelFrontend HostingSOC 2 Type II
StripePaymentsPCI DSS Level 1
AWSInfrastructureSOC 1/2/3, ISO 27001, PCI DSS

Security Training

Employee Training

  • Onboarding: Security training for all new employees
  • Annual: Yearly security refresher training
  • Phishing: Quarterly phishing simulation tests
  • Incident Response: Bi-annual incident response drills

Access Control

  • Principle of Least Privilege: Minimum necessary access
  • Role-Based Access: Access based on job function
  • Regular Reviews: Quarterly access reviews
  • Offboarding: Immediate access revocation

Questions?

For security questions:


Last Updated: 2026-02-24
Version: 1.0