What veriQU creates in your AWS account
Last updated: November 7, 2026
veriQU scans your account through one read-only role. Two optional stacks make changes in your account: the remediation stack changes the settings you choose, and the review stack writes your draft Well-Architected review. Nothing below is created unless you create its CloudFormation stack yourself, under your own credentials, and you can delete any of them at any time.
1. The assessment role (required)
Stack template: assessment-role.yaml, opened from the veriQU console with two values prefilled: veriQU's AWS account ID (818825275202) and an External ID unique to your subscription.
Creates one resource: an IAM role named veriQU-Assessment.
| Part | What it allows |
|---|---|
| Trust policy | Only account 818825275202 may assume it, and only when it presents your External ID (protects against the "confused deputy" problem) |
| Session length | 1 hour by default (you can set 1–12 hours) |
SecurityAudit (AWS managed) | Read security configuration across AWS services |
ViewOnlyAccess (AWS managed) | List and describe resources |
WellArchitectedRead | Read your Well-Architected workloads and reviews |
MarketplaceCatalogRead | Read your Marketplace listings and change sets (to check listing requirements) |
CloudTrailLookup | Look up past API calls (to prove your Marketplace integration was called) |
ResilienceRead | Read AWS Backup, Service Quotas, Resilience Hub and Elastic Disaster Recovery settings |
DetectiveControlsRead | Read Security Hub, GuardDuty, IAM Access Analyzer, Inspector and AWS Config |
CostAndPartnerCentralRead | Read budgets, cost anomaly monitors and your Partner Central solutions |
OperationalRead | Read CloudFormation, CodePipeline, CodeBuild, CodeDeploy, Systems Manager inventory, AWS Health, tags and resource groups |
CredentialReport / IamAnalysisThisAccountOnly | Generate the IAM credential report and simulate IAM policies in this account |
HardDenyDataAccessAndMutation (Deny) | Blocks reading stored data even if another policy would allow it: S3 objects, DynamoDB items, Secrets Manager values, Parameter Store values, KMS decrypt, SQS messages, Lambda code, RDS Data API |
Optional: a permissions boundary of your choice. To revoke access: delete the stack.
2. Remediation stack (optional, one per scan)
Launched only if you choose to apply veriQU's one-click remediations. Each remediation is a Yes/No parameter whose description lists exactly what it changes and what it costs; paid or risky ones default to No.
Always creates:
- A Lambda function that applies only the remediations listed inside it, refuses to run in any other account, and stops if anything fails. On veriQU Continuous it can also run once a day, as described below.
- An IAM role for that function. It holds only the permissions for the remediations you set to Yes, on the exact resources named, plus write access to its own log group.
- A CloudWatch log group,
/veriqu/fixes-apply-<id>, kept after the stack is deleted as the record of what changed (365-day retention).
Creates only if you choose that remediation:
| Remediation | Creates |
|---|---|
| Multi-region CloudTrail | A trail and a private, encrypted, versioned S3 bucket for it |
| AWS Backup coverage | A backup vault, a daily backup plan (35-day retention) and a backup role |
| AWS Config recorder | A private, encrypted S3 bucket for Config history; the Config service-linked role if missing |
| Any alarm or notification remediation, or the daily automatic remediation | An SNS topic for alerts, encrypted with a customer managed KMS key that rotates yearly, and an email subscription for the alert email you enter |
| Failure handling for Lambda functions | An encrypted SQS queue that collects failed events, and an alarm on it |
Daily automatic remediation (veriQU Continuous, AutoRemediate set to Yes) | A daily EventBridge schedule that runs the stack's function; X-Ray tracing on that function; its own failures sent to the alert topic |
Daily automatic remediation (veriQU Continuous only). Once a day the function checks the remediations you set to Yes and covered by the switches AutoRemediate, AutoRemediatePaid and AutoRemediateReviewed, and remediates any that have changed back. It uses the same role as above, plus permission to publish to the alert topic, write traces, and restart logging on the CloudTrail trail this stack created (that trail only). It never rewrites an alarm that exists: it only re-creates veriQU alarms that were deleted. Paid services and reviewed changes are only kept in place if you turn their switch on. Set AutoRemediate to No or delete the stack to stop it.
Changes made by the remediations stay in place when you delete the stack. Deleting the stack also stops the daily automatic remediation, so keep the stack while you want it. The alert topic, its key and the failed-events queue are kept if you delete the stack, because alarms and functions may still point at them; delete them yourself once nothing uses them.
3. Draft Well-Architected review stack (optional)
Launched only if you want veriQU to draft your Well-Architected review.
Creates: a Lambda function, its IAM role (Well-Architected Tool read and write only), and a log group. It creates or updates one Well-Architected workload tagged veriqu:draft, answers only what the scan verified, and adds a note to everything else. You stay the named reviewer.
4. What veriQU never does
- Changes your account through the assessment role. Only the stacks in sections 2 and 3 make changes, and only after you create them.
- Reads the data stored in your account (see the Deny above).
- Creates resources you did not select.
Questions: info@thecloudcatalysts.com