Data Handling

This page is the plain-English version of OpsCurb's trust model.

On this page

• What OpsCurb collects
  • Account and workspace data
  • Scan data
  • Optional capability data
• What OpsCurb does not collect
• Storage and retention
• Deletion behavior
• Encryption and transport
• Secret decryption boundary
• Access controls
• AI and model-provider handling
• Subprocessors and service providers
• Support access
• Related documents

What OpsCurb collects

Account and workspace data

• user email address and profile details needed to operate the workspace
• company and billing metadata
• AWS account identifiers, role ARNs, configured scan regions, and generated external IDs

Scan data

• resource metadata used by the enabled scan capabilities
• cost and utilization summaries from services such as Cost Explorer and CloudWatch metrics
• findings, scan history, accountability fields, and notification settings
• observed AWS API action metadata from scans and Deep Inspect runs for least-privilege review

Optional capability data

• logs_diagnostics: CloudWatch Logs query results are processed transiently and only derived findings are stored
• deep_inspect: derived CloudWatch and CloudTrail evidence is written back to the finding that was inspected
• s3_inventory: bucket-level metadata only
• iam_inventory: IAM user, role, and access-key metadata only
• tag_inventory: tag metadata used for reporting and findings

What OpsCurb does not collect

• S3 object contents
• database row data from RDS
• EC2 filesystem contents or shell access
• AWS secret values from Secrets Manager or Parameter Store
• long-lived AWS access keys from your account

Storage and retention

Deletion behavior

• account deletion requests remove the workspace data from the active product environment
• backups and provider-managed recovery copies can remain until their normal expiration window ends
• privacy and deletion requests are handled through support@opscurb.com

Encryption and transport

• traffic between browser, frontend, API, and managed providers is protected with TLS
• managed providers handle encryption at rest for the primary database, backups, and storage services
• external IDs for AWS role assumption are stored separately from the main account row and encrypted with AWS KMS

Secret decryption boundary

• only backend API services with the configured KMS access can decrypt stored external IDs or notification secrets
• browser sessions, client components, and browser-facing JSON responses do not receive decrypted secret values
• normal settings pages expose secret state as connected/configured metadata rather than returning the secret itself

Access controls

• customer-facing product access is isolated with PostgreSQL Row Level Security
• backend services use server-side credentials for scheduled scans and notifications
• support-driven access should be treated as privileged operational access and is limited to support, debugging, or incident-response needs

AI and model-provider handling

• OpsCurb does not operate a separate customer-data training pipeline for an in-house model
• when AI features are enabled, limited finding context can be sent to the selected model provider in order to generate explanations or guidance
• if your environment does not allow third-party model providers, keep AI features disabled

Subprocessors and service providers

Support access

• support requests are handled through support@opscurb.com
• security questions can be sent to security@opscurb.com
• if your team requires a stricter support or access-review process, raise that before onboarding

Related documents

• Security Policy
• Privacy Policy
• Permissions Matrix