Security & trust

How CloudProof by BuriCloud accesses your AWS, what we do with the data, and how to verify and revoke it. Questions: security@buri.cloud.

What access we take

• Read-only, always. We assume a customer-deployed IAM role using the AWS-managed SecurityAudit + ViewOnlyAccess policies. We never get write/delete permissions.
• You deploy it, you own it. The role is created by a CloudFormation template in your account; it trusts only our scanner principal and is gated by a per-account External ID.
• Nothing runs in your account. No agent, no Lambda, no data-plane — just an IAM role we assume to call read APIs.
• Revoke anytime by deleting the CloudFormation stack (the role). Access stops immediately.

How we handle data

• EU-hosted. Runs in AWS Frankfurt (eu-central-1); your posture data stays in the EU.
• Encrypted at rest (DynamoDB + S3 with AWS KMS / SSE) and in transit (TLS 1.2+ everywhere, HSTS via CloudFront).
• Secrets in AWS Secrets Manager — session and signing keys are never in config files or Terraform state; the app fetches them at runtime by ARN.
• We store configuration posture, not your data. Findings reference resource identifiers and settings — not object contents, secrets values, or customer records.
• Passwordless auth (magic links) — no passwords to leak; sessions are short-lived, signed cookies.

Report integrity

Every report is digitally signed (Ed25519). Anyone can confirm a report is genuine and unaltered at /verify — useful for handing evidence to an auditor.

Air-gapped option

Regulated, classified, or isolated environments can run the same engine as a signed, offline-licensed binary on-prem — no SaaS access to your account at all.

Subprocessors

• Amazon Web Services — hosting (EU).
• Paddle — billing / merchant of record (no AWS data shared).
• Amazon SES — transactional email (sign-in links, alerts).

A DPA is available on request. SOC 2 for CloudProof itself is on our roadmap.