Built for the security review.
Deadlift is sold to engineering teams in regulated environments. The product is structured so that the security questionnaire is short: nothing leaves your AWS account.
Your compliance, not ours.
Because Deadlift runs entirely in your AWS account, our compliance story is essentially "you keep your existing one". We add no new data processor to your scope.
-
SOC 2
Inherited from your AWS account
-
ISO 27001
Inherited from your AWS account
-
HIPAA
Eligible if your account is configured
-
GDPR
Deploy in any region you choose
Architectural principles
The decisions we made up front so the security story is short.
Data residency by design
Deadlift is a CloudFormation template. The entire stack deploys into your own AWS account. There is no SaaS backend to send data to.
Zero data egress
Message bodies, receipt handles, and audit log entries live exclusively in DynamoDB tables in your account. No data plane on our side.
Least-privilege IAM
Every Lambda has its own execution role scoped to the minimum required permissions. No shared roles, no wildcards.
Non-destructive browsing
Deadlift never consumes a message unless you explicitly tell it to. Browsing extends visibility timeout - it doesn't delete.
Cognito authentication
User authentication via Cognito User Pool deployed in your account. MFA on every tier, SAML / OIDC SSO on Enterprise.
Encryption at rest and in transit
DynamoDB AWS-managed encryption. CloudFront HTTPS redirect. AppSync Cognito-issued JWTs over TLS for every request.
Exactly what the template can do.
Every IAM action the CloudFormation template requests, extracted from the synthesized template and grouped by service. Nothing is granted that isn't listed here.
| Service | Actions | Why |
|---|---|---|
| SQS | sqs:ListQueues sqs:GetQueueAttributes sqs:ReceiveMessage sqs:SendMessage sqs:DeleteMessage sqs:ChangeMessageVisibility sqs:PurgeQueue | The core job: list DLQs, browse messages non-destructively, replay them to the source queue, and purge on request. |
| DynamoDB | dynamodb:GetItem dynamodb:PutItem dynamodb:UpdateItem dynamodb:DeleteItem dynamodb:Query dynamodb:BatchGetItem dynamodb:BatchWriteItem | Reads and writes to the five tables the stack creates in your account: sessions, audit log, counters, auto-replay rules, and settings. Scoped to those tables only. |
| CloudWatch | cloudwatch:GetMetricData cloudwatch:PutMetricAlarm cloudwatch:DescribeAlarms cloudwatch:DeleteAlarms | Queue depth charts on the dashboard, plus creating and reconciling the depth alarms that drive alerts. |
| Lambda | lambda:InvokeFunction | AppSync resolver roles invoke the stack's own Lambda functions - each resolver can call exactly one function. |
| S3 / CloudFront | s3:PutObject s3:GetObject* s3:DeleteObject* s3:List* cloudfront:CreateInvalidation cloudfront:GetInvalidation | Deploy-time only: upload the dashboard's static assets to the stack's own bucket and invalidate the CloudFront cache. Never touches your buckets. |
| SNS / Cognito | none | No IAM actions requested at all. The stack creates its own SNS topic and Cognito User Pool as resources; alarms publish to the topic via CloudWatch alarm actions, not an IAM grant. |
Framework plumbing not listed above: CloudFormation custom resources for
log retention (logs:PutRetentionPolicy)
and the asset-deployment helper that CDK generates. Standard
sts:AssumeRole trust policies let each
Lambda assume its own execution role - no cross-account trust anywhere.
Don't take our word for it: the CloudFormation template is published at a public S3 URL, so you can read every permission before you deploy.
What we can never see.
Not "won't look at". Can't. There is no network path from your deployment to us.
Your message payloads
Bodies, attributes, receipt handles - read by Lambdas in your account, stored in DynamoDB in your account, rendered by a dashboard served from your account.
Your queue names and contents
The list of queues, their depths, and everything in them stays behind your account boundary. We have no API that could ask for it.
Your AWS credentials
Deadlift never asks for keys. Operators sign in to your Cognito User Pool; Lambdas assume their own execution roles via the standard runtime.
Your IAM roles and policies
The template creates its own roles and touches nothing else. We cannot enumerate, read, or modify any IAM entity you own.
The only data Deadlift-the-vendor holds is AWS Marketplace billing metadata: your AWS account ID, a customer identifier, and the tier you purchased. AWS provides that to every Marketplace seller - it is how billing works, and it is the whole list.
Answering the security questionnaire.
The questions a security reviewer actually asks. Click any question to read the full answer.
- Where is customer data stored?
- In DynamoDB tables provisioned inside the customer's own AWS account at deploy time. Deadlift has no shared backend or central database. There is no copy of customer data on infrastructure we control.
- Does Deadlift have access to customer message bodies?
- No. The dashboard, AppSync API, Lambda functions, and DynamoDB tables all run inside the customer account. We have no read path in. Customer message bodies are visible only to the operators authenticated against the customer's own Cognito User Pool.
- What outbound network traffic does Deadlift generate?
- Two destinations only: a customer-configured webhook URL for alarm notifications (optional, off by default), and AWS Marketplace for billing metering. Message bodies are never sent to either - the webhook payload is metadata only.
- How are operator actions audited?
- Every replay, edit, and purge writes an audit record to a DynamoDB table in the customer account. Records include the Cognito identity of the operator, action type, target queue, message IDs, and timestamp. Retention is tier-gated (7 / 30 / 90 / 365 days).
- What IAM permissions does Deadlift hold?
- Each Lambda has its own execution role scoped to the minimum permissions for its job. The replay Lambda only holds ReceiveMessage / SendMessage / DeleteMessage on queues in the account. The list Lambda only holds ListQueues / GetQueueAttributes. There is no shared role and no wildcard beyond what's strictly required.
- How are credentials managed?
- Deadlift never asks for or stores credentials. Operators authenticate against the customer's Cognito User Pool. The Lambda functions assume their own IAM execution roles via the standard AWS Lambda runtime - no long-lived keys.
- Is data encrypted at rest and in transit?
- Yes. DynamoDB tables use AWS-managed encryption at rest. CloudFront enforces HTTPS via redirect-to-HTTPS viewer protocol policy. AppSync uses Cognito-issued JWTs over TLS for every authenticated request.
- What happens if Deadlift the company shuts down?
- The CloudFormation stack continues to run inside the customer's AWS account. There is no licence-server check or remote feature flag that the product depends on. Customers retain everything that's already deployed; only future updates would stop arriving.
- Can we delete all Deadlift data?
- Yes - delete the CloudFormation stack and every DynamoDB table, Lambda, Cognito User Pool, and S3 bucket goes with it. There is no shadow copy on our infrastructure because there is no infrastructure on our side.
Have a question we haven't answered?
Send your security questionnaire over and we'll respond within two business days.